[feat] support Azure Static Web Apps in adapter-auto

[geoffrich]

This PR adds a check for Azure Static Web Apps to adapter-auto. If it succeeds, it uses svelte-adapter-azure-swa, which I maintain. This package is not automatically added as a dependency of adapter-auto, users need to install it first.

The check uses the GITHUB_ACTION_REPOSITORY environment variable to check if we are building using the Azure SWA action. Azure SWA builds on GitHub actions by default.

I tested this using patch-package on one of my SWA projects and it seemed to work.

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. All changesets should be patch until SvelteKit 1.0

[changeset-bot]

🦋 Changeset detected

Latest commit: 2ddb045

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@sveltejs/adapter-auto	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[benmccann]

What happens if the user doesn't have it installed?

I'm a bit wary of this as it seems like a slippery slope where we'll start getting PRs to include all the various adapters in adapter-auto

I think adapter-auto needs a rethink. It drives me up the wall because it pulls in all sorts of crazy dependencies into every project via vercel/nft. It should probably install the necessary dependency rather than including them all or we should just kill the package or something

[Rich-Harris]

What happens if the user doesn't have it installed?

This is very much how it's supposed to work — for non-'core' adapters, we tell you how to install the adapter but we don't do it for you. Not a slippery slope, the more the merrier (as long as we don't end up in a situation where there are multiple competing adapters for a given platform).

There's an issue for automatically installing other adapters, precisely because of the @vercel/nft thing, which I would love to get rid of: #5123. If we do that, we could consider making all adapters recognised by adapter-auto install automatically. We should definitely have that conversation but for now I'll merge this — thanks @geoffrich

[Conduitry]

we could consider making all adapters recognised by adapter-auto install automatically

This worries me. I talk in #5123 about the concerns of reproducible builds, and I don't know how we achieve that with third-party adapters without having a release of adapter-auto for every single release of all of these third-part adapters, which sounds like a mess. Unless we want to just say that you don't get the same reproducible build guarantees when pulling in third-party adapters?