feat: log re-optimization reasons #15339
Conversation
|
|
patak-dev
changed the title
| const hash = getDepHash(config, ssr) | ||
| const lockfileHash = getLockfileHash(config, ssr) | ||
| const configHash = getConfigHash(config, ssr) | ||
| const hash = lockfileHash + configHash |
There was a problem hiding this comment.
We are missing getHash here
| const hash = lockfileHash + configHash | |
| const hash = getHash(lockfileHash + configHash) |
Maybe it is better to have a composeHashes util so it is in sync with getDepHash
There was a problem hiding this comment.
Oh I wasn't mean to do another getHash here... because they are hashes already. Do we care about the length getting doubled, or could we simplify contacting them? I'd fix getDepHash if so
There was a problem hiding this comment.
The hash ends up used in the ?v in the optimized module id, good for it to be a hash
|
This will be helpful. I was thinking we should merge it in 5.1 so we dont trigger cold starts in a patch but I just realized that the lock will change. So the change I asked on the other PR was not justified. |
|
Yeah, lock will change anyway. So we don't need to care about cross-version cache compatibility. I was thought you mean that |
patak-dev
changed the title
| if (cachedMetadata.lockfileHash !== getLockfileHash(config, ssr)) { | ||
| config.logger.info( | ||
| 'Re-optimizing dependencies because lockfile has changed', | ||
| ) | ||
| } else if (cachedMetadata.configHash !== getConfigHash(config, ssr)) { | ||
| config.logger.info( | ||
| 'Re-optimizing dependencies because vite config has changed', | ||
| ) | ||
| } else { |
There was a problem hiding this comment.
Just a note, we don't need to account for the transition, when cachedMetadata.lockfileHash and cachedMetadata.configHash are undefined. In that case, the log will be that the lockfile has changed (because of the Vite update) so we are good
Description
So digging into nuxt/nuxt#24196 (comment) we found out the root cause is that the hash is inconsistent across multiple runs (while I need to patch Vite locally to see what has changed). While in a complex setup, some many plugins might cause this race condition and hard to identify. I think it would be better to let users be aware of when and why the optimization cache gets invalidated, so it would help plugin authors to make the more stable behaviors.
Additional context
What is the purpose of this pull request?
Before submitting the PR, please make sure you do the following
fixes #123).