-
-
Notifications
You must be signed in to change notification settings - Fork 1.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
svelte.config.js version changes cause most client chunks to generate a new hash despite no other changes #12260
Comments
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. |
@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). |
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 |
@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! |
Are there any proposals/thoughts for how to address this? How much worse would it be if the content in 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. |
* Revert "fix: replace version in generateBundle (#12700)" This reverts commit 3591411. #12700 did introduce a bug where the file name stays the same, but the contents of a file can change because of a changed version. Revert for now and take another look at tackling this later. Fixes #12771 Reopens #12260 * changeset
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_zp1tl
where 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: vitejs/vite#11911
Reproduction
pnpm create svelte@latest deterministic-build
cd deterministic-build
pnpm i
pnpm build
. copy outputpnpm build
. copy outputLogs
System Info
Severity
serious, but I can work around it
Additional Information
No response
The text was updated successfully, but these errors were encountered: