Uncaught error on startup: Cannot read env of undefined

[HalfdanJ]

Describe the bug

After updating sveltekit from 2.6.2 to 2.6.3, the build version of the app is broken on startup with the following error

public.Dvbes-1E.js:1 Uncaught (in promise) TypeError: Cannot read properties of undefined (reading 'env')
    at public.Dvbes-1E.js:1:376

The code that is running is

const d = globalThis.__sveltekit_1n0gls.env;

I can see that globalThis.__sveltekit_1n0gls doesn't exist, but globalThis.__sveltekit_aqr0w does. So it seems like somehow the keys gets mixed up in the build. I suspect introduced in #12700

Reproduction

1. Create a new sveltekit project, and make a build
2. Take note of the variable name globalThis.__sveltekit_* in client/_app/immutable/chunks/entry.*.js
3. Make a change to package.json, for example add a new dependency
4. Make new build, notice that the entry.*.js file has not changed filename (same key), but that globalThis.__sveltekit_* has changed key, so the file has become mutable

The build is still valid by itself, but if application is served behind a cdn, the old file will be served since filename doesnt change.

Logs

No response

System Info

System:
    OS: macOS 14.6.1
    CPU: (12) arm64 Apple M2 Max
    Memory: 2.38 GB / 64.00 GB
    Shell: 5.9 - /bin/zsh
  Binaries:
    Node: 20.15.1 - ~/.nvm/versions/node/v20.15.1/bin/node
    npm: 10.7.0 - ~/.nvm/versions/node/v20.15.1/bin/npm
    pnpm: 9.1.1 - ~/.nvm/versions/node/v20.15.1/bin/pnpm
    bun: 1.1.5 - ~/.bun/bin/bun
  Browsers:
    Chrome: 129.0.6668.90
    Safari: 17.6
  npmPackages:
    @sveltejs/adapter-node: 5.2.5 => 5.2.5 
    @sveltejs/enhanced-img: 0.3.8 => 0.3.8 
    @sveltejs/kit: 2.6.3 => 2.6.3 
    svelte: 4.2.19 => 4.2.19 
    vite: 5.4.8 => 5.4.8

Severity

blocking an upgrade

Additional Information

No response

[HalfdanJ]

After further looking into this, it seems like this might be a cache / cdn issue. The file public.Dvbes-1E.js is served with the wrong key 1n0gls, but when i look at the docker artifact that has been deployed, the files contains the right key 1lw3djs. Is it possible the change in #12700 resulted in the key changing, but the filename staying the same, and therefore resulting in the file having changed content without changing filename?

[HalfdanJ]

I have isolated the issue and updated the issue to contain reproduction steps. Issue is that the key changes when package.json changes, but the filename doesnt change so it has become mutable.

[sickl8]

Encountered the same problem recently, fixed by enabling "Disable Cache" in browser dev tools for each CI build of a commit

[gwest7]

For me the issue occurred when kit.version.name in svelte.config.js was set to Date.now().toString() manually.

[eltigerchino]

For me the issue occurred when kit.version.name in svelte.config.js was set to Date.now().toString() manually.

Can you open a new issue with a minimal reproduction in the form of a repository?

[ohnv]

For me the issue occurred when kit.version.name in svelte.config.js was set to Date.now().toString() manually.

Just encountered the exact problem as mentioned in the first comment, and this was the issue. I was generating kit.version.name by random GUID + date string at the end. Fixed it by referencing the git commit hash instead.

I also don't think it was related to a CDN, as it affected production builds running locally on my PC.

Interestingly, I deploy 2 apps with a shared codebase (essentially the same package.json, exactly the same same vite config, svelte config etc) and yet it only affected one of them.

🤷‍♂

[tehnrd]

This still seems to be an issue and I spent way too much time debugging this issue before searching Github Issues.

I was trying to use a hash but then fell back to new Date().getTime().toString() and this seemed to be the issue.

[eltigerchino]

This still seems to be an issue and I spent way too much time debugging this issue before searching Github Issues.

I was trying to use a hash but then fell back to new Date().getTime().toString() and this seemed to be the issue.

Can you open a new issue with a minimal reproduction?

[tehnrd]

I will definitely try, but debugging this has been painfully slow. The issue only happens when deployed to AWS ECS with Cloudflare in front. Doesn't repro with npm run dev or after build and preview

Edit: Finally reproduced with local build and preview, will start tearing down the app to create a minimal reproduction. The AWS issue still exists but that is a totally different issue, something with <pre> tags causing illegal invocation error.