You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
ESM is the future, so it would be nice to make it the default. SvelteKit, Astro, Nuxt, vite-plugin-ssr, Hydrogen, and Vitedge are all using ESM already, so it's possible we could stop supporting CJS altogether
Alternative
We could keep CJS around as an option for 3.0 and then drop it in 4.0. There are only a couple known issues and they're both being worked on. It's unclear if they'd be blockers
I don't really see the point in dropping CJS support. Why not let people do what they want?
We haven't decided to drop support for CJS in v3 yet. I think it isn't going to be possible at this point. Maybe there is an intermediate option where we keep it as deprecated with a note of intent that is going to be removed in 6 months or so, or it will be kept but not maintained. Only as a way to give people an easier migration path to Vite v3.
Regarding why we may want to drop support for CJS SSR builds, they currently require the esbuild scanner and the previous externalization logic heuristics. We have cleaned this for the ESM builds, but IIUC we can't do the same for CJS. I think a third option would be to also switch the CJS SSR build to externalization by default, and if users want to use it, they'll have to deal with noExternal themselves.
Clear and concise description of the problem
Vite currently builds SSR code as CJS.
I think that is controlled here:
vite/packages/vite/rollup.config.js
Line 72 in 274c10e
Suggested solution
ESM is the future, so it would be nice to make it the default. SvelteKit, Astro, Nuxt, vite-plugin-ssr, Hydrogen, and Vitedge are all using ESM already, so it's possible we could stop supporting CJS altogether
Alternative
We could keep CJS around as an option for 3.0 and then drop it in 4.0. There are only a couple known issues and they're both being worked on. It's unclear if they'd be blockers
require()
calls of Node built-ins to import statements when emitting ESM for Node evanw/esbuild#2067)Additional context
This was originally suggested here: #8033 (comment)
Validations
The text was updated successfully, but these errors were encountered: