refactor: remove default manualChunks strategy in core, adds split vendor plugin package

[patak-dev]

Description

Alternative to #6534 with the splitVendorPlugin and splitVendor manualChunk strategy function out of Vite core. This PR creates a new package @vitejs/plugin-split-vendor in the monorepo. The plugin is very simple so it uses the same unbundled approach from plugin-vue-jsx

Additional context

Another option is to take this plugin out of the monorepo, or even in a personal account. But I think having it in the monorepo is good enough, we avoid adding a new API to core but it is still discoverable

---

What is the purpose of this pull request?

• Bug fix
• New Feature
• Documentation update
• Other

[Shinigami92]

Mh... my personal note would just be tto move this into it's own repo in the vitejs org
In the long run I thing it would help the ecosystem to have such plugins in it's own scope
The problem of packages inside the monorepo is like the community things it will be fully maintained by us and they don't try to change / update something
But I could be wrong

[patak-dev]

I think it is the other way around, or at least the same. If the project is in the vitejs org it is also the same set of maintainers. That being said, I don't have an issue with moving it out, but the reason shouldn't be to increase maintainability.

[sodatea]

I prefer keeping it inside the core.

• Splitting chunks is too common a use case that it deserves special treatment like minimization.
• Though the configuration is not perfect, it is a good-enough default for many projects.
• I think we shouldn't require users to install yet another plugin to get the standard functionality in other bundling tools.
• It's not much extra code.

[patak-dev]

Edit: corrected my comment here, I thought that soda's comment was in the other PR 🤦🏼

@sodatea so you consider that we should merge #6534 instead of this PR and that the API as defined here is good enough to enable users to continue using the vite <2.7 scheme?

I'm fine with that. The idea to move it out of core was to be able to merge it without committing to an API, but we can always deprecate if we ever came up with more general chunking options. And I didn't want to move it out of the monorepo because of the maintenance burden... that this PR increases anyways so I'm not happy with it either

If this is the case, would you approve #6534?

[sodatea]

I mean I think #6534 is a good short-term solution for now. So I've approved that one.

[patak-dev]

My vote also goes towards #6534

[patak-dev]

Closing this one, we are going to move forward with #6534