-
Notifications
You must be signed in to change notification settings - Fork 2.5k
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(remix-dev/vite): use ssrEmitAssets
to support assets referenced by server-only code
#7892
fix(remix-dev/vite): use ssrEmitAssets
to support assets referenced by server-only code
#7892
Conversation
🦋 Changeset detectedLatest commit: d85fd10 The changes in this PR will be included in the next version bump. This PR includes changesets to release 16 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
packages/remix-dev/vite/plugin.ts
Outdated
// after ssr asset generation, move them to client assets directory | ||
// https://rollupjs.org/plugin-development/#writebundle |
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.
As indicated in vitejs/vite#11430 (comment), one thing this approach could be lacking is that vite's client manifest.json
won't include entries from ssr assets.
I saw vite manifest is used in createBuildManifest/resolveBuildAssetPaths
, but this might not be a critical issue since ssr assets are not something hard-coded by client routes and I don't think it's useful for the purpose of per-route resource pre-fetching etc...
However, if users wish to do their own post-processing based on manifest.json
after vite build && vite build --ssr
, then it may be desired to merge client and server manifest.json
in some way.
ssrEmitAssets
to support assets files referenced by server only codessrEmitAssets
to support assets files referenced by server only code
b54c8e3
to
1a225c0
Compare
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.
@hi-ogawa Thanks for the PR! I pushed a big update with the following changes:
- We now only move SSR assets if they're not already present in the client build
- We log to the terminal which SSR-only assets were moved so consumers can see what's happening
- We clean up the SSR assets dir afterwards since the server doesn't need it (and in my testing it also contains built, unminfied CSS too)
I'm keen to hear what you think!
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.
Nice! The logging looks good and it would definitely help not just for users but also for the sake of debugging when there is something wrong with vite ssr assets.
I added a few minor comments and I'll fix up my own typo, but other than that, feel free to take over the PR and merge!
Co-authored-by: Hiroshi Ogawa <[email protected]> Co-authored-by: Pedro Cattori <[email protected]>
ssrEmitAssets
to support assets files referenced by server only codessrEmitAssets
to support assets referenced by server-only code
… by server-only code (#7892) Co-authored-by: Mark Dalgleish <[email protected]> Co-authored-by: Pedro Cattori <[email protected]>
Closes: #7847
I'm not so sure how robust this change is (especially
writeBundle
plugin hook), but it think it should achieve mostly same thing as what sveltekit did in sveltejs/kit#9073.See this comment #7847 (comment) for more references (especially vite's "stabilizing" discussion vitejs/vite#13808).
I added a test only for
build
case. I think this is not relevant fordev
since vite serves assets files directly without moving or renaming file name with content hash etc..., so I didn't add a test.Please let me know if there are others cases to be covered by tests.
Testing Strategy: