Open rory-orennia opened 1 month ago
Conduitry
commented
1 month ago You need to set https://kit.svelte.dev/docs/configuration#version to something consistent; otherwise, it uses the current timestamp, which changes every build, affecting the hashes.
rory-orennia
commented
1 month ago @Conduitry Ohh thank you! That was definitely it. I guess now my concern is, how is this supposed to work in the case of making a vendor.js file? Unless I hardcode the version to something and then ignore the svelte version handling, I'm still going to get a different vendor.js file every time I do a new commit (assuming you tie version to git like is suggested). I think even if I manually pulled this version check out into another chunk, it would be referenced by most other client chunks in the app and thus they would also change their hash.
rory-orennia
commented
1 month ago Here's me changing the svelte.config.js -> version -> name from 1 to 2 and it basically changing every client chunk
mquandalle
commented
1 month ago If two compiled files across two distincts app versions are exactly the same, why not keep the same file name to avoid unnecessary cache invalidation on the client?
rory-orennia
commented
1 month ago If two compiled files across two distincts app versions are exactly the same, why not keep the same file name to avoid unnecessary cache invalidation on the client?
That's the problem. They aren't exactly the same because some base level sveltekit code gets changed, and then most client code chunks import that change, which causes them to change because the hash they reference (eg. import somebasefile.constantlychanginghash.js) has changed.
If the cause of all of this is the version check code, I think we need to find a way to make that code not bleed into every client chunk
rory-orennia
commented
1 month ago @eltigerchino @Conduitry Do you want me to close this ticket and open a new one that is the new problem? (Version changes cause most client chunks to generate a new hash despite no other changes). Or do you want me to rename this one instead?
eltigerchino
commented
1 month ago @eltigerchino @Conduitry Do you want me to close this ticket and open a new one that is the new problem? (Version changes cause most client chunks to generate a new hash despite no other changes). Or do you want me to rename this one instead?
Yes, renaming this one would be great. Thanks!
matindow
commented
2 weeks ago Are there any proposals/thoughts for how to address this?
How much worse would it be if the content in version.json were replaced with something like a junction map of component names => file paths that all of the chunks referenced dynamically? I am assuming there are a lot of really great/important benefits to being able to hardcode a static file import into all of the chunks that make this a non starter?
I'm trying to think through other ways of doing this version check, and everything seems to come back to the same frictions.
I do agree that incrementing the version number should intuitively not cascade into a new hash for unchanged files in your project, though. Seems not great even aside from the terrible caching issues.
Updated bug report
Changing the version in svelte.config.js and rebuilding the exact same code results in most client chunks also being updated with a new hash. The cause seems to be the version check code being updated to look for a new version, and then most client chunks directly or indirectly importing that change.
Initial bug report
Describe the bug
If you build the same project twice, you get different files out even though nothing has changed.
I was trying to break my project up using manualChunks to create a vendor.js file with the hope that while we're deploying multiple times a day, our dependencies rarely change so clients would reuse many of the same js files they'd already have cached from previous visits. In practice this doesn't work because some base level thing that many pieces inherit from is constantly changing so you never get the same vendor.js file out between builds.
The issue seems to be around a randomly generated key in the output like
globalThis.__sveltekit_zp1tlwhere that hash changes every build. That shows up as the main difference in entry.{hash}.js which many other files then import.I thought this should work since Richard Harris actually raised this bug with Vite: https://github.com/vitejs/vite/issues/11911
Reproduction
pnpm create svelte@latest deterministic-buildcd deterministic-buildpnpm ipnpm build. copy outputpnpm build. copy outputLogs
System Info
Severity
serious, but I can work around it
Additional Information
No response