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
fix: browser cache of newly discovered deps #7378
Conversation
✅ All green vite-ecosystem-ci run against this PR |
Some questions 😬
I'm curious how/why
I'm a bit confused of why we need another hash, given chunks are already hashed in their file name. I think I'm missing a piece here. |
Each discovered dep gets a new browser hash based on every optimized + discovered dep, so
Import analysis is also performed in these chunks adding the browser hash to its imported paths, so the hash from the file name isn't enough because for the same file content we may end up needing to use different browser hashes in these imports. See also #7350, this was the problem in #7323 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
After re-reading the code a few times, I think I understand most of the whys here now. LGTM.
Released in vite@2.9.0-beta.4 |
Description
I'm working to see if it is possible to have the scan phase be also non-blocking, and it is showcasing some issues with the current approach we started at #6758
An important observation is that we can only safely use
'max-age=31536000,immutable'
for requests when we are using dependencies versioned withbrowserHash
after a cached start, initial scan phase, or after discovery+full-reload. ThebrowserHash
that is computed for each newly discovered deps isn't fit for long-term caching with the approach previous to this PR. The issue is hard to manifest but it could happen when:dep_a
that gets assignedbh_a
bh_a
and has a bundleo_a1
)--force
on server restartdep_a
that gets assignedbh_a
dep_b
that gets assignedbh_b
dep_a
ends up withbh_a
but with bundleo_a2
.o_a1
because the version isbh_a
a. This PR solves this issue by including a server timestamp in the
browserHash
of newly discovered deps.b. It also fixes versioning of chunks and dynamic imports, as they should get a stable hash, and they can be safely cached long term using the main
browserHash
c. It also fixes an issue with the computing of
alteredFiles
that was broken due to paths, so it was always true.Note: I think we should add a
fileToDepInfoMap
to speed up searching for depInfo from a file, which we are starting to do quite a bit.What is the purpose of this pull request?