-
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): tree-shake unused route exports #8468
Conversation
🦋 Changeset detectedLatest commit: 6a60267 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 |
@@ -796,10 +809,27 @@ export const remixVitePlugin: RemixVitePlugin = (options = {}) => { | |||
}); | |||
await viteChildCompiler.pluginContainer.buildStart({}); | |||
}, | |||
transform(code, id) { | |||
async transform(code, id) { |
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.
Reading through the Vite conventions for virtual modules again and wondering if we should do something to ensure the client routes don't get processed/handled by other plugins. We could just prepend with \0
or model them fully as vmods.
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.
I think it should be okay if it's handled by other plugins. In terms of resolving the module, since it's a real file on disk, it'll be treated the same as the original route file. In terms of transforming the file, it's going to behave as if you'd manually written a re-export file, which also would work fine.
The benefit of this approach from what I understand is that Vite will treat this pseudo-virtual module the same as the route file in terms of file changes, invalidation, HMR. This means we don't need to do anything special to invalidate virtual modules when the underlying route changes.
🤖 Hello there, We just published version Thanks! |
🤖 Hello there, We just published version Thanks! |
🤖 Hello there, We just published version Thanks! |
Similar to our existing compiler, this PR wraps all client route modules with a virtual module that re-exports all Remix client route exports. This means that any custom route exports that aren't consumed within the client module graph will be removed in the production build. I've added a test asserting that this is the case.
Note that while this is only of value in the production build, I've used the same technique in dev for consistency. This makes it easier to understand how Remix works from both a debugging and a teaching perspective.