Fatal Error [ERR_REQUIRE_ESM]: require() of ES Module vite-ssr\server\pageFiles.mjs not supported

[arthurgailes]

Description

This error occurs when routing to a page that I have not explicitly pre-rendered. (e.g. localhost/notAPage) It only occurs when serving the production build (SSG or SSR).

At some point between 0.4.54 and 0.4.60, this changed from merely printing to the console to causing my express server (basically a copy of the react boilerplace) to crash completely.

In 0.4.54:

Error [ERR_REQUIRE_ESM]: require() of ES Module [workspaceRoot]\dist\apps\hilton\vite-ssr\server\pageFiles.mjs not supported.
Instead change the require of [workspaceRoot]\dist\apps\hilton\vite-ssr\server\pageFiles.mjs to a dynamic import() which is available in all CommonJS modules.
    at [workspaceRoot]\dist\apps\hilton\vite-ssr\server\importBuild.cjs:28:68
    at async Promise.all (index 0)
    at async loadBuild ([workspaceRoot]\node_modules\.pnpm\vite-plugin-ssr@0.4.54_33oe7thcih3clfsuwaxtnji33q\node_modules\vite-plugin-ssr\dist\cjs\node\plugin\plugins\importBuild\loadBuild.js:19:57)
    at async getGlobalContext ([workspaceRoot]\node_modules\.pnpm\vite-plugin-ssr@0.4.54_33oe7thcih3clfsuwaxtnji33q\node_modules\vite-plugin-ssr\dist\cjs\node\globalContext.js:28:30)
    at async initializePageContext ([workspaceRoot]\node_modules\.pnpm\vite-plugin-ssr@0.4.54_33oe7thcih3clfsuwaxtnji33q\node_modules\vite-plugin-ssr\dist\cjs\node\renderPage.js:128:27)
    at async renderPage_ ([workspaceRoot]\node_modules\.pnpm\vite-plugin-ssr@0.4.54_33oe7thcih3clfsuwaxtnji33q\node_modules\vite-plugin-ssr\dist\cjs\node\renderPage.js:31:41)
    at async renderPage ([workspaceRoot]\node_modules\.pnpm\vite-plugin-ssr@0.4.54_33oe7thcih3clfsuwaxtnji33q\node_modules\vite-plugin-ssr\dist\cjs\node\renderPage.js:158:16)

In 0.4.60:

[workspaceRoot]\node_modules\.pnpm\vite-plugin-ssr@0.4.60_33oe7thcih3clfsuwaxtnji33q\node_modules\vite-plugin-ssr\dist\cjs\node\plugin\plugins\importBuild\loadBuild.js:19
    const [pageFiles, clientManifest, pluginManifest] = await Promise.all([
                                                        ^
Error [ERR_REQUIRE_ESM]: require() of ES Module [workspaceRoot]\dist\apps\hilton\vite-ssr\server\pageFiles.mjs not supported.
Instead change the require of [workspaceRoot]\dist\apps\hilton\vite-ssr\server\pageFiles.mjs to a dynamic import() which is available in all CommonJS modules.
    at [workspaceRoot]\dist\apps\hilton\vite-ssr\server\importBuild.cjs:28:68
    at async Promise.all (index 0)
    at async loadBuild ([workspaceRoot]\node_modules\.pnpm\vite-plugin-ssr@0.4.60_33oe7thcih3clfsuwaxtnji33q\node_modules\vite-plugin-ssr\dist\cjs\node\plugin\plugins\importBuild\loadBuild.js:19:57)
    at async initGlobalContext ([workspaceRoot]\node_modules\.pnpm\vite-plugin-ssr@0.4.60_33oe7thcih3clfsuwaxtnji33q\node_modules\vite-plugin-ssr\dist\cjs\node\globalContext.js:32:30)
    at async renderPage ([workspaceRoot]\node_modules\.pnpm\vite-plugin-ssr@0.4.60_33oe7thcih3clfsuwaxtnji33q\node_modules\vite-plugin-ssr\dist\cjs\node\renderPage.js:17:5) {
  code: 'ERR_REQUIRE_ESM'
}

Error Message + Error Stack

No response

[brillout]

Other than Vite, are you using another bundler that is bundling dist/server?

What's the output of the following?

$ cat dist/server/importBuild.cjs

(I.e. the cat equivalent for Windows.)

[arthurgailes]

No, I run the "cross-env NODE_ENV=production ts-node ./server" command. The build process is just vite build.

{
const { setLoaders } = require('../../../../../node_modules/.pnpm/vite-plugin-ssr@0.4.60_33oe7thcih3clfsuwaxtnji33q/node_modules/vite-plugin-ssr/dist/cjs/node/plugin/plugins/importBuild/loadBuild.js');
setLoaders({
pageFiles: () => import('./pageFiles.mjs'),
clientManifest: () => require('../client/manifest.json'),
pluginManifest: () => require('../client/vite-plugin-ssr.json'),
});
}

[arthurgailes]

I think that leads in the right direction; was finally able to reproduce it using the boilerpate. It's somewhere in my tsconfig settings; I'll test and report back.

[arthurgailes]

Ok, the message can be reproduced by adding "allowJs": true to compilerOptions in tsconfig.json in the react-ts boilerplate, and running npm run prod.

0.4.55 is the update that converts this from an error message to a complete break.

Edit: a temporary workaround is to also add "allowJs": false to ts-node's compilerOptions.

[brillout]

Neat, thanks for the comfy repro.

That's quite unexpected, I'll have a look at it.

FYI it should work since importBuild.cjs does use import():

pageFiles: () => import('./pageFiles.mjs'),

[brillout]

Ok, the message can be reproduced by adding "allowJs": true to compilerOptions in tsconfig.json in the react-ts boilerplate, and running npm run prod.

I couldn't reproduce: https://github.com/brillout/vps-reprod-573.

[arthurgailes]

navigate to localhost:3000/thing. The app crashes as above for me.

Edit: actually, this seems to crash for me in all cases (even visiting localhost:3000 after running npm run prod), using either windows or wsl.

Edit2: also failed on a separate Ubuntu computer. This works for you?

[amirhoseynShourideh]

I have the exact same problem.
With removing "allowJs": true the mentioned error is I guess fixed but I get errors like:

Error [ERR_UNSUPPORTED_DIR_IMPORT]: Directory import 'P:\Files\Vite-SSR\node_modules\@mui\material\Button' is not supported resolving ES modules imported from P:\Files\Vite-SSR\dist\server\assets\_default.page.server.64e310fb.js Did you mean to import @mui/material/node/Button/index.js? at new NodeError (node:internal/errors:393:5) at finalizeResolution (node:internal/modules/esm/resolve:319:17) at moduleResolve (node:internal/modules/esm/resolve:916:10) at defaultResolve (node:internal/modules/esm/resolve:1124:11) at nextResolve (node:internal/modules/esm/loader:163:28) at ESMLoader.resolve (node:internal/modules/esm/loader:841:30) at ESMLoader.getModuleJob (node:internal/modules/esm/loader:424:18) at ModuleWrap.<anonymous> (node:internal/modules/esm/module_job:76:40) at link (node:internal/modules/esm/module_job:75:36)

Edit: I tried the boilerplate and I and the same error happened.

[arthurgailes]

@amirhoseynShourideh Are you using Vite 4? The update caused a similar error for me with Chakra, not related to VPS.

[amirhoseynShourideh]

@arthurgailes yes I do.
Any suggestions on how to fix this or related issues?

[arthurgailes]

Downgrade to version 3, and it should work again. The package authors will likely release a fix soon, if they haven't already. Chakra just did a few hours ago, so I doubt it will take MUI much longer.

[amirhoseynShourideh]

I downgraded to "vite": "3.2.5" problem still persists. Any idea?

[arthurgailes]

Only this, otherwise no, we're getting a bit off-topic: https://vite-plugin-ssr.com/invalid-esm

[amirhoseynShourideh]

@arthurgailes Thanks. I had to delete node_modules and reinstall to fix Error [ERR_REQUIRE_ESM]: require() of ES Module ...

[arthurgailes]

Did that fix the boilerplate for you?

[amirhoseynShourideh]

No It didn't.
But it is fixed on my actual project.

[brillout]

navigate to localhost:3000/thing. The app crashes as above for me.

Edit: actually, this seems to crash for me in all cases (even visiting localhost:3000 after running npm run prod), using either windows or wsl.

Edit2: also failed on a separate Ubuntu computer. This works for you?

Alright, I could reproduce.

The culprit is ts-node which transpiles import('./pageFiles.mjs') to await Promise.resolve().then(() => __importStar(require('./pageFiles.mjs')));.

The workaround is to set tsconfig.json#moduleResolution to Node16/NodeNext.

[brillout]

Boilerplates updated, see c697843 to see how I solved it for the boilerplates.

I think we can close this. Let me know if there is anything else.

[samuelstroschein]

I recommend taking a look at TypeScript Execute (TSX) https://github.com/esbuild-kit/tsx to avoid ESM-related issues with ts-node. It worked out of the box for the project I am working on which is ESM only, in contrast to ts-node.

[brillout]

@samuelstroschein Yea also thinking of TSX. Maybe even Deno... but I don't know how far they are with their npm compat layer.

[samuelstroschein]

@brillout TSX works flawlessly. See TSX in action on the project I am working on https://gitpod.io/#https://github.com/inlang/inlang.

RE: deno, lovely, but I expect several unforseen edge cases like this one.

[brillout]

Last time I tried TSX I had issues with it. I'll give it another shot.

RE: deno, lovely, but I expect several unforseen edge cases like this one.

FYI https://twitter.com/biwanczuk/status/1607332213384974336.

[brillout]

@samuelstroschein FYI privatenumber/tsx#167. The slowness of tsx is a no-go. I also don't like how tsx handles error (but I could live with that). Quite a pity, tsx seems really nice otherwise.

[samuelstroschein]

@brillout Thanks for the heads up. #562 seems to be the way to go. Avoid ts-node and TSX altogether.

[brillout]

I agree that'd be nice, it's just lower priority because the long term idea is for the user to use (something like) HatTip. But in the meantime it'd definitely be nice indeed.