No adapter by default

[Rich-Harris]

A question someone is likely to have early on in their SvelteKit journey is 'how will I deploy this thing?' If someone does the natural thing of running npm run build to see what happens, they'll be given a Node app via adapter-node, which is possibly the most awkward thing to deploy of all the options.

The only other adapter that isn't tied to a specific platform is adapter-static, but that's no good since it's also the only adapter that can only handle a subset of Svelte apps.

Solution: begin with no adapter, and npm run build gives you some feedback along these lines:

$ npm run build

No adapter specified!

To build your Svelte app, you must specify an 'adapter' depending on how you will deploy the app.

For more details, visit https://svelte.dev/docs#adapters.

> Select an adapter to set it up automatically: 
✔ Skip this (I'll do it manually or come back later)
  @sveltejs/adapter-node
  @sveltejs/adapter-static
  @sveltejs/adapter-begin
  @sveltejs/adapter-cfw
  @sveltejs/adapter-netlify
  @sveltejs/adapter-vercel

The user types e.g. cfw to filter the list...

> Select an adapter to set it up automatically: 
✔ @sveltejs/adapter-cfw

...and hits enter...

✔ Installed @sveltejs/adapter-cfw
✔ Updated svelte.config.js

You can swap this adapter out for a different one at any time.

> Creating unoptimized build...
  ✔ server
  ✔ client

> Optimizing...
  ✔ server
  ✔ client

> Generating app (@sveltejs/adapter-cfw)...
  Prerendering static pages...
  Pruning manifest...
  Bundling workers...
  ✔ done

[Conduitry]

What happens if they do Skip this (I'll do it manually or come back later)? Do we still build anything, but none of it's currently usable? Do we abort the build? In either case, I think the menu option should make the behavior more clear.

Are we currently installing anything to node_modules on behalf of the user? If so, with what package manager? If not, what would we use here? - since presumably, they will already have installed dependencies before running stuff with npm run dev. Do we look for lockfiles and detect the package manager to use?

This does overall seem like a reasonable idea, though.

[Rich-Harris]

Do we still build anything, but none of it's currently usable? Do we abort the build?

I think we abort the build altogether:

> Select an adapter to set it up automatically: 
✔ Abort (I'll set this up manually and/or come back later)
  @sveltejs/adapter-node
  @sveltejs/adapter-static

Are we currently installing anything to node_modules on behalf of the user?

No, the closest we get is modifying package.json during initialisation. I think detecting lockfiles is probably best, and if none is found defaulting to npm (and then deleting the resulting lockfile?)

[Conduitry]

Aborting makes sense to me.

The least work for us would probably be to abort the build after updating package.json as well (and tell people to re-install dependencies) but yeah it does seem polite to detect at least npm/yarn/pnpm and run one accordingly.

[dominikg]

Detecting the package manager in use can be challanging and it can change over time, eg. npm7 now reads from yarn.lock (it still uses package-lock.json but presence of yarn.lock may not guarantee that user wants yarn)
May be better to leave that to the user.
Editing package.json should properbly also respect indentation and linebreak scheme eg: https://github.com/conventional-changelog/standard-version/blob/master/lib/updaters/types/json.js

[benmccann]

Perhaps this functionality makes sense to put in create-svelte

[babichjacob]

Does this also serve the purpose of satisfying #129?
That is to say, that people who want to build component libraries can use dev like normal, and their build command works about the same (i.e. the Snowpack and Rollup steps) without running an adapter step?

[Rich-Harris]

In the component library case I don't think you'd run svelte-kit build at all, except for the accompanying demo site. There'd need to be another command (svelte-kit package? svelte-kit bundle? svelte-kit create-component-library?) that took the contents of your src/components folder (or whatever other folder you specified) and a) applied preprocessors, b) generated type declarations, c) created an export map, etc.

In any case, I'm starting to wonder if there should be a separate svelte-kit adapt command, so that the different steps are more clearly delineated, and viewing the unadapted built production app locally (with svelte-kit start aka npm start) is promoted as a more normal thing. adapt would only need to happen at deploy time (e.g. in CI).

[benmccann]

svelte-kit adapt command was added in #221

[Conduitry]

What should the default template have in it now that adapt has been moved to a separate command from build? I'm not sure what makes the most sense.

[benmccann]

I think build should run svelte-kit build && svelte-kit adapt. Although #221 doesn't describe the motivation for splitting the two commands apart and I wonder if we want to keep it that way. Right now it seems like it introduces extra usability overhead since one is not useful without the other.

The case where I could see it being useful to have two separate commands is if you wanted to support multiple adapters, which I don't think it something we support right now. But in that case I could see it saving build time because you could just build the common files / app once and then adapt it to two different platforms. The case where I see having two adapters being useful is that many adapters can't easily be run locally right now (e.g. lambda/function type adapters). It might be useful to run the node adapter for local testing in that case. We have npm run start, but it runs a separate server that we have to keep somewhat in sync with the node adapter and might not be as powerful - this came up in #367

[benmccann]

I think this was mostly fixed by #430:

kit/packages/kit/src/cli.js

Line 114 in f1bc218

console.log(colors.bold().yellow('\nNo adapter specified'));

@Rich-Harris was there anything else to do here or should we close this one?

[Rich-Harris]

Yeah i think we can close it