why are you assuming that a major release breaks compatibility?
https://semver.org/ https://docs.npmjs.com/about-semantic-versioning
That’s the sole reason for the squiggly marks and carets that exist in every package.json.
I get it, Linux does its own thing with versions, and so do browsers, so it's hip to just increment major whenever you feel like it apparently.
EDIT: LOL at people downvoting GP because they dared to wonder if the frontend world needs another bundler shipping a non-compatible major version at least once a year. Stockholm Syndrome I guess, who doesn't want to update their configuration and see their plugins break every year?
Even Go, one of the most boring (in the good sense) languages, considered to do the same thing at some point (when included generics).
This is why when you npm add a dependency it defaults to the "^1.2.3" syntax, which means the dependency is upgradeable to the next minor version, which, as SemVer states, should be guaranteed to be backwards compatible.
Of course you can just disregard that, make breaking changes whenever you want and annoy your users enormously.
https://docs.npmjs.com/cli/v8/configuring-npm/package-json#v...
https://docs.npmjs.com/about-semantic-versioning
AFAIK Go doesn't follow any kind of versioning scheme (since they don't use a versioned module manager), but the project itself is semver-compliant. No breaking changes are introduced since Go 1.0 was released. The proposals for breaking language changes will be planned for Go 2.0. Generics aren't breaking old code.
There is no reason, unless your name is Linus Torvalds or you're marketing driven such as your browser, not to follow Semver. It's a good and simple idea.
I have no knowledge of which convention Vite uses.