Make Vite a prod dep?

[Conduitry]

Is your feature request related to a problem? Please describe.
Given its active development, it seems reasonably likely that Vite will continue to add features that we'd like to make use of. Once we come out of beta and release SvelteKit 1.0, it will be a breaking change whenever we want to make use of a newer version of Vite - if it continues to be a peer dependency.

Describe the solution you'd like
If Vite (and possibly the Svelte-Vite plugin) were production dependencies of Kit, we could ensure that they are upgraded when someone upgrades Kit.

Describe alternatives you've considered
We could do nothing. There are several other places we use peer dependencies (like the Rollup plugin has a peer dependency on a certain minimum version of Svelte), but these don't need updating very often. Unless we wait ages for SvelteKit 1.0 for Vite to be more or less feature complete, it seems likely they'll add something we'd like to use.

How important is this feature to you?
I think it's fairly important to at least see what would be involved in doing this. I don't want major versions on Kit to bump excessively, and I don't want to be hobbled with supporting an old version of Vite.

Additional context
Not really. I guess doing this will make it a bit less clear to people how to upgrade only Vite without upgrading Kit, but that seems like a worthwhile tradeoff for all the flexibility this will afford us.

[Conduitry]

Another more ideological argument in favor of this is that users aren't really creating a Vite app. Kit uses Vite under the hood, but users aren't actually directly calling Vite anywhere, and there are a limited number of places where Kit users are able to or need to interact with Vite's API or features or configuration.

But this sort of argument is definitely secondary to ones about new requirements being breaking changes.

[Rich-Harris]

Definitely sympathetic to these arguments. The one counterargument would be that it makes it harder for people to upgrade to newer versions of Vite unless we get round to updating the version Kit depends on, which is arguably less of a big deal. vite-plugin-svelte is a prod dependency of Kit already

[Conduitry]

Oh, I thought I had double checked that the Vite plugin was a peer dep, but evidently not.

Yeah I mentioned the part about it being trickier to update just Vite in 'additional context'. I think requiring a little more package manager adroitness is well worth it, because the alternative is to have it be impossible to force a Vite upgrade.

[benmccann]

I like it better as a peer dep. The the end user has more control instead of us denying or forcing an upgrade upon someone. Although I'm also okay playing fast and loose with sem ver or doing frequent major version releases so that we're not stuck being unable to use new Vite features

[Conduitry]

We'd never deny someone an upgrade - they'd just have to be a little more package manager savvy to upgrade an indirect dependency. And we wouldn't be forcing an upgrade any more than we already would with a peer dep - unless you mean that you want people to be able to use versions of Vite that we know are going to be too old. Being lax about semver is a bad idea, because people will definitely raise issues. And having tons of major versions also doesn't seem great, because it will give people the wrong idea about the stability of the project and will distract from times when we really do need to indicate a more significant breaking change.

[Rich-Harris]

Very much agree with that last point — the 'integers are free' semver purist crowd is detached from reality, we shouldn't emulate them

[Rich-Harris]

closed via #1374