fix: pin adapter versions in adapter-auto

[dummdidumm]

MUST be released before #8740 is merged

version is used to pin the installed adapter version and should point to the latest version of the adapter that is compatible with adapter-auto's current peerDependency version of SvelteKit. Will prevent adapter-auto from accidentally installing adapter versions that are possibly incompatible with the user's SvelteKit version.

Please don't delete this checklist! Before submitting the PR, please make sure you do the following:

• It's really useful if your PR references an issue where it is discussed ahead of time. In many cases, features are absent for a reason. For large changes, please create an RFC: https://github.com/sveltejs/rfcs
• This message body should clearly illustrate what problems it solves.
• Ideally, include a test that fails without this PR but passes with it.

Tests

• Run the tests with pnpm test and lint the project with pnpm lint and pnpm check

Changesets

• If your PR makes a change that should be noted in one or more packages' changelogs, generate a changeset by running pnpm changeset and following the prompts. Changesets that add features should be minor and those that fix bugs should be patch. Please prefix changeset messages with feat:, fix:, or chore:.

[dummdidumm]

@geoffrich FYI you need to bump this when you create a new major of the azure adapter

[geoffrich]

Thanks for the heads up 👍

[benmccann]

is there some way to get these automatically populated from the workspace? it seems like it's going to be really easy to overlook bumping these, which might cause more trouble that it solves

[dummdidumm]

We can't automatically bump them because the mechanism can't know if the bump warrants a major release of adapter-auto or not.
Example:

• adapter-vercel releases new major but peerDep on SvelteKit stays the same -> should be a minor release in adapter-auto
• adapter-vercel releases a new major and bumps peerDep on SvelteKit -> should be a major release in adapter-auto

[Conduitry]

Do we have the ability to specify semver ranges here of the other adapters? It might not be what's happening here, but I can imagine a situation where an adapter has a breaking change because of what options it accepts, but that change is irrelevant for people consuming it through the auto adapter because it doesn't let you specify any options anyway. Are we prepared for that sort of situation?

[Rich-Harris]

I think we could just bump the adapter version here and it would be harmless, no? It's just a matter of remembering to do it

[Conduitry]

Probably, yeah. I'm not sure what I was thinking about with the range. I think I had forgotten that the auto adapter doesn't itself have peer dependencies on the other adapters.

[benmccann]

Another idea - what if we downloaded the latest major version of the adapter from npm and checked its peer dependency. If it's not compatible we decrement the major version and try again

[Conduitry]

That assumes that there won't be any other types of breaking changes besides peerdep bumps, which doesn't sound safe to me.

[benmccann]

Maybe we could add a lint check that checks if you have a major changeset for an adapter you've also updatedpackages/adapter-auto/adapters.js?

[Rich-Harris]

Would only work for the adapters in this monorepo. I think it's probably more complexity than its worth, I don't anticipate breaking changes happening often

[benmccann]

Yeah, probably won't be too frequent. Though I do think that bumping the adapters' major version will happen more (e.g. if we change some options) than we add new API in kit. Maybe instead of introducing these versions we should bump the peer dependency version that adapter auto specifies on kit. Then we know anyone who's using the latest adapter-auto will have access to the new API added in kit.

[dummdidumm]

That doesn't work, because without a version restriction you would get the latest version of an adapter which might have a newer peerDependency requirement than adapter-auto

[benmccann]

You'd have to bump the adapter-auto peer dependency to be the highest of any of the adapters it can install. The advantage is that you'd have to do that less frequently than you'd have to bump the major version of an adapter

[dummdidumm]

Maybe we are talking past each other. This PR suggests exactly that:

• each time an adapter has a major release that bumps its peerDependency on SvelteKit, adapter-auto will also get a major release that bumps its peerDependency of SvelteKit (to the highest of all adapters it can install)
• in order to not accidentally install adapter-vercel version 2.0 which needs SvelteKit 1.5 through adapter-auto version 1.2, we need a way to tell the adapter what maximum version of each adapter to install, and this PR does that.