Error: Dynamic require of "x" is not supported

[lovasoa]

Describe the bug

Upgrading to the latest version of sveltekit broke adapter-node for my application. Now the application works in development, but when packaged by adapter-node, it throws `` on start

Reproduction

It can be reproduced on lovasoa/sanipasse@79c310b

lovasoa/sanipasse@79c310b

Logs

file:///home/olojkine/dev/sanipasse/build/middlewares.js:26
  throw new Error('Dynamic require of "' + x + '" is not supported');
        ^

Error: Dynamic require of "crypto" is not supported
    at __require (file:///home/olojkine/dev/sanipasse/build/middlewares.js:26:9)
    at node_modules/@peculiar/webcrypto/build/webcrypto.js (file:///home/olojkine/dev/sanipasse/build/middlewares.js:8119:19)
    at __require2 (file:///home/olojkine/dev/sanipasse/build/middlewares.js:32:44)
    at node_modules/isomorphic-webcrypto/src/index.js (file:///home/olojkine/dev/sanipasse/build/middlewares.js:10253:22)
    at __require2 (file:///home/olojkine/dev/sanipasse/build/middlewares.js:32:44)
    at node_modules/isomorphic-webcrypto/src/main.js (file:///home/olojkine/dev/sanipasse/build/middlewares.js:10262:22)
    at __require2 (file:///home/olojkine/dev/sanipasse/build/middlewares.js:32:44)
    at file:///home/olojkine/dev/sanipasse/build/middlewares.js:10271:46
    at ModuleJob.run (node:internal/modules/esm/module_job:183:25)
    at async Loader.import (node:internal/modules/esm/loader:178:24)

System Info

System:
    OS: Linux 5.13 Fedora 34 (Workstation Edition) 34 (Workstation Edition)
    CPU: (8) x64 Intel(R) Core(TM) i7-10510U CPU @ 1.80GHz
    Memory: 2.64 GB / 15.28 GB
    Container: Yes
    Shell: 5.1.0 - /bin/bash
  Binaries:
    Node: 16.5.0 - /usr/bin/node
    Yarn: 1.22.10 - /usr/bin/yarn
    npm: 7.19.1 - /usr/bin/npm
  Browsers:
    Firefox: 91.0.2
  npmPackages:
    @sveltejs/adapter-node: next => 1.0.0-next.46 
    @sveltejs/adapter-static: next => 1.0.0-next.18 
    @sveltejs/kit: next => 1.0.0-next.165 
    svelte: ^3.38.3 => 3.42.5 

Severity

blocking all usage of SvelteKit

Additional Information

No response

[lovasoa]

If I manually change the generated build/middlewares.js to add global.require = createRequire(import.meta.url); at the top, the app starts normally

[quentincaffeino]

Also got this issue but with another package.

@lovasoa how about renaming title to Error: Dynamic require of "x" is not supported since it doesn't really depend on which package you are importing? For me this happened with package tty, which was imported by supports_color package.

I updated each package separately in my project to find the cause of the issue and interestingly this is caused by eslint-plugin-svelte3 version 3.2.1. Works on version 3.2.0. @lovasoa also has his package updated in lock file.

[dummdidumm]

That's very strange, from 3.2.0 to 3.21 there shouldn't be a difference related to dynamic requires.

[quentincaffeino]

Also wonder how this happens, but I know nothing of svelte sources so...

This is require function before:

var __require = (x) => {
  if (typeof require !== "undefined")
    return require(x);
  throw new Error('Dynamic require of "' + x + '" is not supported');
};

and after updating eslint-plugin-svelte3:

var __require = typeof require !== "undefined" ? require : (x) => {
  throw new Error('Dynamic require of "' + x + '" is not supported');
};

Problem could be within immediate condition execution but I'm not sure how.

[lovasoa]

I tried to update all the dependencies and just pin [email protected], and the problem is still present, so this is probably not where the bug is.

[lovasoa]

Manually resetting the old definition of __require in middlewares.js does prevent the error from occurring. The global require is undefined when __require is defined at the top of the file, but is then dynamically added by the init_shims calls.

[dummdidumm]

This sounds like some bundler (esbuild?) changed the transpilation (the __require thing) which does not account for a dynamically added require. Question is if the init_shims can somehow be moved above it.

[lovasoa]

I made a PR to esbuild to revert the change. See my comment there.

[Conduitry]

I've commented on that PR with more SvelteKit context to help esbuild maintainers understand why we need this.

I've also found evanw/esbuild#946 which appears to be the main issue for why we needed this shim in the first place. I haven't checked whether the other suggested workarounds in that issue (like the banner one, for example) will still help us here even with the change to __require.

[lovasoa]

Maybe the quick fix here in svelte is to publish a release that uses banner, to prevent more people updating their dependencies from breaking their project ?

This is quite an annoying bug, because there is no obvious way to know where it comes from for the end user, who may spend a lot of time looking for a bug in their own code.

[Conduitry]

evanw/esbuild#1604 (comment) It sounds like this won't be fixed/supported soon on the esbuild side. We probably should look into a banner solution or, failing that, a hacky manual editing of the bundled file after esbuild outputs it.

[lovasoa]

Maybe there can even be a temporary fix where the esbuild version is pinned ? This can be done without any implementation work, and would fix all the sveltekit projects that have been broken for two weeks now.

[jim-fx]

@lovasoa, very nasty hack, which works for me right now:

bin/nastyHack.cjs:

console.log('Executing naasty hack, check https://github.com/sveltejs/kit/issues/2400 for updates');

const fs = require('fs');
const { resolve } = require('path');

const buildPath = resolve(__dirname, '../build/index.js');

const data = fs.readFileSync(buildPath, 'utf8');

const newLine = `const require = createRequire(import.meta.url)
        `;
fs.writeFileSync(buildPath, `${newLine}${data}`, 'utf8');

package.json build script:

{
   "scripts": {
      "build": "svelte-kit build && node bin/nastyHack.cjs"
   }
}

[dummdidumm]

esbuild just released a new version which contains a require shim which should fix this.
I'm not sure if there's anything else we need to do here, as the adapter-node package should load the latest esbuild version when installed.

[0gust1]

We were hit by this today.

@dummdidumm

We just updated the package-lock.json of our project (rm -rf node_modules package-lock.json && npm i) : esbuild was updated to 0.12.29.

We deployed on our staging env (our build and deploy uses npm ci so it obeys to the lockfile) and it works again.

(strange thing: We were unable to reproduce the problem locally this morning but our staging env was broken)

[Conduitry]

Awesome! From Evan's comment the other day, it didn't sound like it was going to be fixed that quickly.

I do think it is worth making changes on our end rather than just closing this issue. We should probably try removing our own require shim from the Node adapter and bumping the minimum esbuild version.

[Conduitry]

From some brief tests, it looks like we still do need the require shim. This makes sense in hindsight because esbuild's new __require function

var __require =
	/* @__PURE__ */ (x =>
		typeof require !== 'undefined' ? require :
		typeof Proxy !== 'undefined' ? new Proxy(x, {
			get: (a, b) => (typeof require !== 'undefined' ? require : a)[b]
		}) : x
	)(function(x) {
		if (typeof require !== 'undefined') return require.apply(this, arguments)
		throw new Error('Dynamic require of "' + x + '" is not supported')
	})

still doesn't actually do any createRequire stuff. So, evanw/esbuild#946 isn't fixed, and their shim doesn't define require, but at least it won't get in the way of our require. It still might be good to explicitly update our esbuild dependencies to ^0.12.29 throughout this repo, but I don't think we should make any other changes at this time.

[benmccann]

Vite's on 0.12.28 at the moment, but we'll upgrade to 0.13.2 when Vite 2.6 comes out: dominikg#1

[benmccann]

The latest version of SvelteKit now uses esbuild 0.13.2. It sounds to me like this is probably now fixed as a result, but feel free to correct me if that's wrong and we can reopen

[Conduitry]

Yup, all that should have been needed was folks upgrading their transitive esbuild dependency to 0.12.29, which didn't require any action on SvelteKit's part. But we've now updated to 0.13 anyway, so we should be good.

[AlexRMU]

The same thing after #6372

var __require = /* @__PURE__ */ ((x) => typeof require !== "undefined" ? require : typeof Proxy !== "undefined" ? new Proxy(x, {
    get: (a, b) => (typeof require !== "undefined" ? require : a)[b]
}) : x)(function (x) {
    if (typeof require !== "undefined")
        return require.apply(this, arguments);
    throw new Error('Dynamic require of "' + x + '" is not supported');
});

...

var crypto_1 = __importDefault(__require("crypto"));

Perhaps the problem is evanw/esbuild#1921

[AlexRMU]

If I add

import { createRequire } from "module";
const require = createRequire(import.meta.url);

before var __require, this will appear:

node:internal/modules/cjs/loader:933
  const err = new Error(message);
              ^

Error: Cannot find module '../lib/utils.js'
Require stack:
- ...\build\server\chunk-BHN6OJC3.js

in

// node_modules/.pnpm/[email protected]/node_modules/uglify-js/tools/node.js
var require_node2 = __commonJS({
  "node_modules/.pnpm/[email protected]/node_modules/uglify-js/tools/node.js"(exports) {
    var fs = __require("fs");
    exports.FILES = [
      __require.resolve("../lib/utils.js"),
      __require.resolve("../lib/ast.js"),
      __require.resolve("../lib/transform.js"),
      __require.resolve("../lib/parse.js"),
      __require.resolve("../lib/scope.js"),
      __require.resolve("../lib/compress.js"),
      __require.resolve("../lib/output.js"),
      __require.resolve("../lib/sourcemap.js"),
      __require.resolve("../lib/mozilla-ast.js"),
      __require.resolve("../lib/propmangle.js"),
      __require.resolve("../lib/minify.js"),
      __require.resolve("./exports.js")
    ];
    ...