Typescript serverless functions seem to be failing for me with
{"errorType":"Error","errorMessage":"Dynamic require of \"util\" is not supported","trace":["Error: Dynamic require of \"util\" is not supported"," at __require (file:///var/task/functions/data.js:28:9)"," at node_modules/util-deprecate/node.js (file:///var/task/functions/data.js:86:22)"," at __require2 (file:///var/task/functions/data.js:31:44)"," at node_modules/faunadb/src/query.js (file:///var/task/functions/data.js:6328:21)"," at __require2 (file:///var/task/functions/data.js:31:44)"," at node_modules/faunadb/index.js (file:///var/task/functions/data.js:8742:17)"," at __require2 (file:///var/task/functions/data.js:31:44)"," at file:///var/task/functions/data.js:8760:33"," at ModuleJob.run (internal/modules/esm/module_job.js:183:25)"," at process.runNextTicks [as _tickCallback] (internal/process/task_queues.js:60:5)"]}
Regular .js functions with the same exact code works fine.
I’ve had a support email unanswered for two days about that issue .
We now started to replicate our Netlify Functions as GCP Cloud Functions to ensure mission-critical code continues to be available and to have more redundancy - and a migration path off Netlify should we need to go down that path.
Btw, another idea may be to use tsc or similar to convert the Typescript functions to Javascript before deploying, but I feel that’s less ideal than what I described with GCP above.
Yea, i’m using tsc to pre compile the scripts beforehand and since netlify automatically uses JS files before TS files it seems to be a valid workaround
Netlify engineer here. We’ve been making some changes around our ES Modules support that could explain a different behaviour in esbuild. I’ve disabled the new logic temporarily — could you let me know if you’re still experiencing the issue?
On February 21st at 09:33 UTC, we rolled out an update to the Netlify Functions bundling logic that changed the module format of functions in certain conditions. Rather than transpiling all functions using ES Modules to CommonJS, as we’d been doing since we introduced support for that format, we started generating pure ESM functions under certain conditions:
When the configured functions runtime environment is Node 14, and
When there is a package.json file with {"type": "module"} as an ancestor of the function file.
If any of the conditions above weren’t met, we continued transpiling the functions to CJS.When we started generating ESM functions, we inadvertently hit a known issue with esbuild, the open-source JavaScript bundler we use internally. This issue makes esbuild generate faulty code when:
An ESM file imports a CJS file, and
The CJS file requires a Node built-in module (like fs or path ), and
The target format of esbuild is set to esm
We’ve since rolled back the update and we’re back to transpiling all ESM functions to CJS until we have a temporary solution in place. We’ve also updated our test suite to include this specific setup, to ensure we don’t see this regression again.
I am experiencing this problem for the first time today with a newly published release. There was no problem for our Friday release, and I have found nothing apparent in our commits since.