feat(core): use virtual file system for SRI #435
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Types of changes
Description
This PR brings a technical rewrite of the way we save SRI hashes at build time.
Previously, the way we saved SRI hashes was hacky. We were writing the hashes on the drive under the
.nuxt
build-time directory, which was necessary for SSG rendering of integrity hashes. But because this directory is not available in the server context in SSR mode, we also copied them to the server assets output folder. Then we relied onuseStorage
to retrieve the hashes, and depending whether the context was SSR or SSG, we had to look either into thebuild
folder orassets
folder. Because the output was in JSON format, we encountered issues when Nitropack changed the format of raw assets in JSON format (most notably #395).With this rewrite, we now use the native Nuxt Virtual File System to inject SRI hashes at build time. In practice, this means that the SRI hashes are now directly bundled into the Nitro server runtime. We do not need
useStorage
to read them from the disk anymore.This closes #395 definitively as we remove the dependency from
useStorage
raw format.Checklist: