Vite: client references to .server code result in build-time error #8184
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.
Remix already ensures that all code from
.serverfiles (and now also.serverdirectories) gets replaced with an empty module, so there's no way for.servercode to end up in the client. Ideally, all references to.servercode get stripped in the client anyway, but replacing them with empty modules is a failsafe. In the case that there are still imports for.serverfiles in the client, those will correctly result in errors.However, those errors could sometimes happen at runtime, meaning that it was possible for your CI/CD pipeline to pass and for you to deploy your app only for your users to hit a "cannot reference
.servercode within the client" error. This is already much better than leaking server data in the client, but still not ideal. Specifically, this could happen when usingdefaultexports within a.serverfile/directory.This PR adds test to ensure that named imports, namespace imports, and default imports from
.serverfiles/directories all fail at build time. That ensures that your CI/CD pipeline fails before you ever deploy any references to (empty).servermodules that could result in ugly errors for your users.To get
defaultexports to fail at build time, we needed to switch our empty module stub fromexport default {}toexport {}. So this PR also makes that change.