Skip to content
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

WIP: vite-plugin-react-swc integration #9092

Draft
wants to merge 2 commits into
base: dev
Choose a base branch
from
Draft

Conversation

pcattori
Copy link
Contributor

Copy link

changeset-bot bot commented Mar 20, 2024

⚠️ No Changeset found

Latest commit: 268e2d9

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

return { code, map: result.map };
},
},
reactPlugin(),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

😍

@pcattori
Copy link
Contributor Author

For React plugin to function correctly, we need to only create ?client-route virtual modules in production, not in development. Currently, the React plugin will only add React Refresh header/footer to files that define React components (which is correct), but the virtual modules re-export React components defined in their corresponding route modules. We used to manually inject React Refresh header/footer for these vmods too when we vendored/modified the React plugin.

?client-route vmods exist solely to guarantee same production-mode treeshaking from classic (esbuild-based) Remix compiler still happens when migrating to Remix Vite. Originally, I was opposed to having ?client-route vmods exist only in the prod module graph, but since they exist solely to power optimizations like treeshaking that only get applied in prod, its ok for that part of the module graph to be different. Especially since these vmods are one-liners that just re-export client-safe exports, so there isn't a bunch of complexity that could trip us up.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants