Proposal: Drop CJS support already in Vite 3

[brillout]

I'm concerned whether the whole CJS compact layer is worth it. I'd say: let's rip the band aid off. There are enough examples of ESM-only environments (e.g. SvelteKit) showing it's possible and, more importantly, worth it to go for ESM-only.

If we go for ESM-only in 12 months with Vite 4, that's 12 more months carrying the whole CJS baggage around. It slows us down. At the end of the day, I see Vite becoming a better tool if we drop CJS with Vite 3 already, because we'll be able to focus on higher priority things than CJS support.

@patak-dev @antfu

[patak-dev]

There is now a lot of code in the repo to support the SSR CJS builds (the scanner, plugin-commonjs, externalization logic, node require hook plugin). But some of these pieces are still needed in case a project has issues with the new discovery scheme during dev and build, or problems with using esbuild optimization during dev. So even if the SSR CJS build would be dropped, we still need them.

But I agree that moving forward, the cost of maintaining all these pieces is too high. As an example, we can't yet upgrade to plugin-commonjs v22 and I don't know who is going to spend time doing that now (#7894).

I think we have three options:

1. We keep everything but mark things as deprecated, and we remove them on v4.
2. We keep everything but explicitly tell the ecosystem that we are leaving the options to go back only as a way for people to have more time to upgrade. Then we remove them in a minor (let's say 3.5). Once we do so, we would still allow people to use the SSR CJS build but without the externalization logic (the user must do that manually if needed)
3. We only provide ESM SSR in 3.0.0 (and CJS SSR without externalization), and we also remove the scanner and plugin-commonjs. If users have issues, they need to stay in 2.9.

The problem I see with 3. is that the ecosystem is going to move forward quickly and require support for v3... so we are probably going to leave people behind if they have issues. We may also need more testing and time to go out with 3. instead of 2.

My current stance is that we should go with 2., and leave the door open for us to remove these pieces during the next year once we know that the new schemes are good for every user.

[patak-dev]

Yes, what I like about 2 is that users would still be able to stay in v3.5 let's say if needed, and we could even backport some critical fixes for a while if needed. But v3.5 would still be compatible with the moving ecosystem

[IanVS]

Then we remove them in a minor

Am I misunderstanding, or does this mean making a breaking change in a minor release? That seems like it would be pretty disruptive.

[brillout]

@IanVS No: it's basically Vite 3 breaking changes with a grace period.

[patak-dev]

Yes, the breaking change will be informed in Vite 3, and the old strategies will be opt-in marked as experimental and deprecated. But this is just speculation at this point, we still need to discuss what is the best strategy moving forward.

[patak-dev]

For reference, the PR implementing option 2:

• feat: legacy options to revert to v2 strategies #8623

[xieyuheng]

Vite 5.0 Deprecates CJS!