Netlify Serverless Typescript functions fail with dynamic requires

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 (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’m using sveltekit and faunadb

We encounter the same thing.

The last successful function execution I see was at Feb 21, 02:58:10 AM PST and the first one that threw the exception was at Feb 21, 06:40:53 AM PST.

There are no deployments from our side in this time period.

This is currently a high priority issue for us as it blocks important Netlify functions from running.

I’m also seeing this. My setup hasn’t changed, but functions started failing sometime between Monday 21st and now.

I’ve had a support email unanswered for two days about that issue :frowning:.

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.

My functions are written in plain JS, but with ES modules. Perhaps the way esbuild is used has changed somehow.

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

Could one of you provide a reproduction of this?

EDIT: Also, this is probably related: Working on netlify dev, not on actual deploy · Issue #1036 · netlify/zip-it-and-ship-it · GitHub

as soon as i try to use faunadb or firebase-admin i immediatly get Dynamic Require Errors…

for example (typescript file)

Path: .netlify/functions/faunaTest.ts

import faunadb from 'faunadb' /* Import faunaDB sdk */

/* configure faunaDB Client with our secret */
const q = faunadb.query
const client = new faunadb.Client({
  secret: process.env.FAUNADB_SECRET

export const handler = async function (event, context) {

	const t = {success: "success"};
	return  {
		statusCode: 200,
		body: "success"

yes, appears to be same issue

Hi all,

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?



It looks to be working now.
I am no longer seeing a Dynamic Require error

great. we have switched off the code that make the error happened, and will continue investigating. We’ll keep you posted.

If anyone still sees the error, please let us know!

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:

  1. When the configured functions runtime environment is Node 14, and
  2. 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:

  1. An ESM file imports a CJS file, and
  2. The CJS file requires a Node built-in module (like fs or path ), and
  3. 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.


Incredible transparency :heart_eyes:. Thank you for the post-mortem!

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.

Were the February 21 changes rolled out again?

cc: @fool

This was pretty difficult to fix. This is what was found: