fix: pin adapter versions in adapter-auto #8874
Conversation
`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.
| }, | ||
| { | ||
| name: 'Azure Static Web Apps', | ||
| test: () => process.env.GITHUB_ACTION_REPOSITORY === 'Azure/static-web-apps-deploy', | ||
| module: 'svelte-adapter-azure-swa' | ||
| module: 'svelte-adapter-azure-swa', | ||
| version: '0.13' |
There was a problem hiding this comment.
@geoffrich FYI you need to bump this when you create a new major of the azure adapter
| export const adapters = [ | ||
| { | ||
| name: 'Vercel', | ||
| test: () => !!process.env.VERCEL, | ||
| module: '@sveltejs/adapter-vercel' | ||
| module: '@sveltejs/adapter-vercel', | ||
| version: '1' |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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-vercelreleases new major but peerDep on SvelteKit stays the same -> should be a minor release in adapter-autoadapter-vercelreleases a new major and bumps peerDep on SvelteKit -> should be a major release in adapter-auto
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
|
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 |
|
That assumes that there won't be any other types of breaking changes besides peerdep bumps, which doesn't sound safe to me. |
|
Maybe we could add a lint check that checks if you have a major changeset for an adapter you've also updated |
|
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 |
|
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 |
|
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 |
|
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 |
|
Maybe we are talking past each other. This PR suggests exactly that:
|
MUST be released before #8740 is merged
versionis 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:
Tests
pnpm testand lint the project withpnpm lintandpnpm checkChangesets
pnpm changesetand following the prompts. Changesets that add features should beminorand those that fix bugs should bepatch. Please prefix changeset messages withfeat:,fix:, orchore:.