Binaries node_modules dependencies missing when deployed to Vercel
Unanswered
Coton de Tulear posted this in #help-forum
Coton de TulearOP
Hi all,
In my next.js app I have a dependency that includes binaries that need to be present at runtime when an api handler is invoked. Specifically, the dependency is
When running locally, the binary is present under its node_modules directory (specifically as
However, when running on Vercel, the binary is absent, with the node_modules subdirectory including only
I don't know whether the binary is being filtered out or not installed at all. I have tried various incantations of
Any help very much appreciated!!
In my next.js app I have a dependency that includes binaries that need to be present at runtime when an api handler is invoked. Specifically, the dependency is
ffmpeg-static. When running locally, the binary is present under its node_modules directory (specifically as
node_modules/.pnpm/ffmpeg-static@5.2.0/node_modules/ffmpeg-static/ffmpeg).However, when running on Vercel, the binary is absent, with the node_modules subdirectory including only
index.js and package.json.I don't know whether the binary is being filtered out or not installed at all. I have tried various incantations of
outputFileTracingIncludes in nextConfig.experimental with no luck , such as:const nextConfig = {
//...
experimental: {
serverComponentsExternalPackages: ['ffmpeg-static', 'fluent-ffmpeg'],
outputFileTracingIncludes: {
'/api/public/myapi/*': ['**/ffmpeg-static*/**/*'],
},
},
//...
};Any help very much appreciated!!
1 Reply
Coton de TulearOP
To follow up, the above approach with
It's very interesting to me how requests handling different API paths can have completely different filesystems, the content of which can be influenced – in ways that are undetectable in dev – by these config directives that have no safety nets if you include typos... Looking forwards to hours of debugging when I rename an API! 😄
outputFileTracingIncludes was the right thing to do. The only issue was that I had a typo in my API path...!It's very interesting to me how requests handling different API paths can have completely different filesystems, the content of which can be influenced – in ways that are undetectable in dev – by these config directives that have no safety nets if you include typos... Looking forwards to hours of debugging when I rename an API! 😄