loadDistEntries error in prod build after upgrading from v0.3 to v0.4

Description

After upgrading from v0.3.64 to v0.4.19, I followed the migration guide to get the dev environment up and running (and it’s working great - in particular, fixes a FOUC issue that I used to see on every page load in the dev environment, so very excited about being able to use the new version!). However, when testing the production build, I run into this issue on the first page request:

[15:49:04.924] INFO: Server running at http://0.0.0.0:3000
::ffff:127.0.0.1 - - [12/Aug/2022:03:49:11 +0000] "GET /api/auth/session HTTP/1.1" 200 2 "-" "undici"
Error: [vite-plugin-ssr@0.4.19][Bug] You stumbled upon a bug in vite-plugin-ssr's source code. Reach out at https://github.com/brillout/vite-plugin-ssr/issues/new or https://discord.com/invite/qTq92FQzKb and include this error stack (the error stack is usually enough to fix the problem). A maintainer will fix the bug (usually under 24 hours). Do not hesitate to reach out as it makes vite-plugin-ssr more robust. Debug info (this is for the vite-plugin-ssr maintainers; you can ignore this): `{"entryFile":"/app/node_modules/vite-plugin-dist-importer/dist/autoImporter.js"}`.
    at loadDistEntries (/app/node_modules/vite-plugin-ssr/dist/cjs/node/plugin/plugins/distEntries/loadDistEntries.js:16:28)
    at getGlobalContext (/app/node_modules/vite-plugin-ssr/dist/cjs/node/globalContext.js:26:29)
    at initializePageContext (/app/node_modules/vite-plugin-ssr/dist/cjs/node/renderPage.js:123:27)
    at renderPage_ (/app/node_modules/vite-plugin-ssr/dist/cjs/node/renderPage.js:30:41)
    at renderPage (/app/node_modules/vite-plugin-ssr/dist/cjs/node/renderPage.js:153:16)
    at pageHandler (/app/services/portal/backend/backend/index.ts:101:25)

The error seems to indicate that distEntries is null, so I tried following the instructions here to manually import the dist/server/importBuild.cjs file in my entrypoint, but it doesn’t seem to make a difference whether it’s there or not. My dev environment doesn’t fit any of the criteria described in #403 - it’s just plain Node 16, with npm as a package manager, although it is inside an npm workspace, so the node_modules folder (/app/node_modules) is a couple of levels up from the package directory (/app/services/portal). This is running inside a Debian Bullseye Docker dev environment. The only other possibly weird thing I’m doing is running the app using node -r esbuild-runner/register.

I added some logging to the loadDistEntries file, and I can see setDistEntries being called, but when loadDistEntries is subsequently called, distEntries is always null.

I noticed even stranger behaviour when I added the following to that same file:

setInterval(() => {
  console.log("distEntries", distEntries);
}, 1000);

It initially produces logs as follows, with a single log line per second, as expected:

distEntries null
[16:30:41.059] INFO: Server running at http://0.0.0.0:3000
distEntries null
distEntries null
distEntries null
distEntries null
...

But then as soon as I navigate to one of the pages, it produces two different log messages each second:

...
distEntries {
  pageFiles: [Function: pageFiles],
  clientManifest: [Function: clientManifest],
  pluginManifest: [Function: pluginManifest]
}
distEntries null
distEntries {
  pageFiles: [Function: pageFiles],
  clientManifest: [Function: clientManifest],
  pluginManifest: [Function: pluginManifest]
}
distEntries null
...

The null value is the one that is obviously being used when loadDistEntries is called, every time a page request is made.

I’m pretty stumped as to how this is occurring, and I feel like I’ve exhausted my understanding of the Node/Vite/VPS internals, so I’m curious if you have any insight! 😅

Error Stack

(See above)

[brillout]

👍 Let me know if there is anything else.

(Btw. I just created a GitHub sponsorship page in case that’s something you’d be interested in. But not worry if you don’t 😃.)

[bradchristensen]

Good call! It didn’t occur to me that we could stash the distEntries in the global scope. That fixes it - thank you so much for the very speedy patch.