feat!: remove ssr proxy for externalized modules#14521
Conversation
benmccann
left a comment
There was a problem hiding this comment.
I've seen users struggle with knowing that they sometimes have to do import * as pkg. I wonder if there's some sort of warning we could print in dev mode when they don't do this in order to guide them towards the correct solution?
There's actually an instance of this in Vite you can test out. vite/playground/ssr-deps/src/app.js Lines 24 to 25 in b868033 Without the We can definitely add more hints/suggestions here, but I think we can improve on that in a later PR. |
|
Yeah, I wasn't sure if users know how to fix it though. The error message could be tweaked a bit to include a solution like |
|
I think we should wait to see how users are often hitting this before adding the hints. I'm afraid to add some suggestions that could be misleading otherwise. Plus there's a lot of resource for that error message on the web that they should be able to find different solutions to what they're hitting. |
sapphi-red
left a comment
There was a problem hiding this comment.
LGTM (If the github discussion link is updated later)
|
It would be nice to add this to docs/guide/migration.md. |
|
/ecosystem-ci run |
|
📝 Ran ecosystem CI: Open
|
Description
Implements solution 2 of #14503
SSR-externalized module are now not handled with special
.defaultand.__esModulehandling access in dev, matching the behaviour in prod. Non-externalized modules stay the same, they are already ESM after all.The main change is to not call
proxyESM. The rest are created for better error messages to identify how to fix it.I also added
legacy.proxySsrExternalModulesto return to the previous behaviour.Additional context
See #14503 for more context.
What is the purpose of this pull request?
Before submitting the PR, please make sure you do the following
fixes #123).