adapter-auto

[Rich-Harris]

Describe the problem

I've seen feedback from Vercel customers that SvelteKit 'doesn't work', because it wasn't clear to them that they needed to add an adapter. Even though it's documented reasonably well, it's definitely a source of friction. It would shock me if people using Kit with other platforms weren't experiencing the same thing.

Describe the proposed solution

There's probably a lot of value in having Kit auto-detect common platforms and build itself accordingly. (Nuxt does this, for example.) To that end I propose something like this in the default template:

import adapter from '@sveltejs/adapter-auto';

export default {
  kit: {
    adapter: adapter()
  }
};

TBD which platforms would be supported here, but the adapters tend to be fairly small and have overlapping dependencies, so we can probably be generous.

Alternatives considered

Builds could fail noisily if an adapter isn't configured. This would help with diagnosis, but it's still friction.

Importance

would make my life easier

Additional Information

No response

[bluwy]

Would #2479 help with this? I think it's a good start before we go with something automatic.

[antony]

does it actually require an adapter module at all? couldn't the default behaviour just be to find and install the relevant adapter (and print a warning that you should probably configure your project correctly?)

[TheOnlyTails]

I imagine this being integrated into the SvelteKit package itself, so users won't have to wonder what a seemingly unimportant package is doing in their project.

However, I do think it should still be required for the adapter field, so it won't be completely magical, and could even lead to discovery by users wondering "what's this doing here? better look it up!"

[Conduitry]

@antony Going out and downloading an adapter on the fly was the behavior Rich originally suggested in the most recent Svelte maintainers call, which seemed to me to be a slightly gross mixing of concerns. I had then suggested making this be its own adapter instead, so the logic for picking an adapter can live solely in an adapter, rather than in SvelteKit core.

[Rich-Harris]

#2479 probably would help, but it has downsides of its own — for people who just want to try Kit out (and have no intention of deploying their experiment, or don't yet know what it should be) it's a premature decision. It also adds complexity to the project scaffolding itself (overwriting a magic placeholder, etc(.

I had then suggested making this be its own adapter instead, so the logic for picking an adapter can live solely in an adapter, rather than in SvelteKit core.

exactly this — good to keep it separate, I think. And having it be 'just another adapter' makes it easier for people to figure out where and how to change it, if they have more niche requirements

[benmccann]

Would adapter-auto be the default? Would it have an explicit dependency on the other adapters? Would it support only official adapters or also community adapters?

I think the thing that makes me most hesitant is that it seems like it could make community adapters slightly more like second-class citizens. It will give people more reason to campaign to make their adapters official adapters, but it's not scalable for us to be responsible for all these adapters on different platforms that we can't easily test and don't necessarily even have accounts on. There are some major platforms primarily supported by community adapters today, and I'm glad the community is handling them

[antony]

slightly gross mixing of concerns

yep - I was thinking of what parcel does and I agree it makes me somewhat uneasy, though it is convenient.

good to keep it separate, I think

agreed, and I can see the reason now. I'm probably slightly concerned that the default behaviour of SvelteKit would now be "install all adapters" though, but I suppose an experienced user would then just uninstall the auto adapter and that would be fairly clean.

it could make community adapters slightly more like second-class citizens

For me the reasoning here is twofold:

• We can't possibly know about every single community adapter
• We can't install every single community adapter as a dependency of adapter-auto

Therefore what I might suggest is some sort of way of defining a heuristic such that community adapters can open a PR to allow auto-detection of their destination platform, which could then print a hint about where to get hold of such an adapter, but going slightly short of actually having it preinstalled (which of course also poses a security risk)

[sphinxc0re]

What about prompting the developer with a choice of adapters along the lines of what create-svelte does?

[TheOnlyTails]

@sphinxc0re as Rich has already said:

#2479 probably would help, but it has downsides of its own — for people who just want to try Kit out (and have no intention of deploying their experiment, or don't yet know what it should be) it's a premature decision. It also adds complexity to the project scaffolding itself (overwriting a magic placeholder, etc).

[sphinxc0re]

Oops, sorry didn't see that 😓

[Tropix126]

My main concern is that a package like this will work as a one-size-fits-all for many deployment targets, but be slightly worse than the more "specialized" adapters alone. It would also discourage people from properly configuring their projects to work with a specific deployment type if included by default, because I imagine many would gloss over a config option they don't understand but also doesn't seem to affect anything.

[benmccann]

A Svelte Adder that could add any adapter could be another solution for this. That would mean you don't have to decide at project creation time what adapter you want to add and allow us to support community adapters and avoid issues around adding dependencies on every single adapter

[gterras]

The problem seems to be you can't hide and teach adapters at the same time and some people need one or the other. I think an elegant way would be npm run configure (ran on initial build) that would display a choice between auto/specific/community.

It would be at the right time of development, wouldn't mix concerns and could teach or promote as much as needed.

[Tropix126]

The problem seems to be you can't hide and teach adapters at the same time and some people need one or the other. I think an elegant way would be npm run configure (ran on initial build) that would display a choice between auto/specific/community.

It would be at the right time of development, wouldn't mix concerns and could teach or promote as much as needed.

The problem is that the configuration step usually happens during the creation wizard; adding an additional script here seems rather redundant.

My personal thoughts are that it's safe to say that most people wanting to create a SvelteKit project plan to deploy it. If they are just "trying it out", then knowledge of adapters is useful information to have in the event they do try to deploy a project later on.

[jthegedus]

Is there a way for me to test out my adapter installs properly if it were to be added to the adapter-auto?

[bluwy]

Is there a way for me to test out my adapter installs properly if it were to be added to the adapter-auto?

If you add your adapter as a dependency of adapter-auto and add it to adapters.js, it should then work. I'd recommend reading the adapter code too.

---

This issue seems to already be resolved by #2867. Closing this.

[benmccann]

I think Rich didn't want all community adapters as dependencies, but instead just detect the platform and spit out a message telling the user they can install it?

[bluwy]

Yeah that's true. We probably don't want anymore community adapters as dependencies for adapter-auto. (I thought my comment had mentioned that but I must've accidentally deleted it)