add yargs dep to allow programmatic prompt answering

[afreidz]

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

Changesets

• If your PR makes a change that should be noted in one or more packages' changelogs, generate a changeset by running pnpx changeset and following the prompts

Problem

Running npm init svelte@next requires user interaction to a series of prompts. If a package wishes to leverage this scaffolding command, it would need to expose these prompts upstream. In some cases, it may be preferable to pass the options to the command instead of using an interactive prompt. Example: I plan to make a yeoman generator for use within our company to create scaffold sveltekit apps. We have decided that TS,eslint,prettier are all required and not optional. I wish not to burden our consumers with having to answer the prompts in ways that match our suggestions.

Solution

Leveraging yargs it is fairly trivial to parse CLI flags passed into bin.js and use those to values in place of the prompts. This allows programmatic completion of the npm init svelte@next command. In our use case, this will allow us to hard code the answers and not burden our consumers with answering them.

[babichjacob]

👍 to the concept for sure (not tested the implementation yet). This will be useful for svelte-add's initializer to wrap create-svelte's (hinted at here and here).

[Conduitry]

If we make this more programmatic, I'm concerned about that implying an API that we won't want to stick with. E.g., if we add a new question that someone hasn't yet added an option for in their script, is this a breaking change because running create-svelte now expects user input and won't just run automatically. (The alternative would be to make it explicitly fail if some but not all options were specified on the command line, which would also be a breaking change.) If this tool always requires human interaction, we don't need to worry about having an API because we can always assume a human is reading the interactive prompts.

[afreidz]

I pulled up the docs for prompts which is leveraged in create-svelte and under the "override" section (damn them for not deep linking 😄 ) they had this example:

[afreidz]

If we make this more programmatic, I'm concerned about that implying an API that we won't want to stick with. E.g., if we add a new question that someone hasn't yet added an option for in their script, is this a breaking change because running create-svelte now expects user input and won't just run automatically. (The alternative would be to make it explicitly fail if some but not all options were specified on the command line, which would also be a breaking change.) If this tool always requires human interaction, we don't need to worry about having an API because we can always assume a human is reading the interactive prompts.

i believe the impl is that any questions not passed a matching CLI param would still be prompted, rather than breaking. but, yea, i guess the decision is how to break unfortunately ☹️

[babichjacob]

If we make this more programmatic, I'm concerned about that implying an API that we won't want to stick with. E.g., if we add a new question that someone hasn't yet added an option for in their script, is this a breaking change because running create-svelte now expects user input and won't just run automatically. (The alternative would be to make it explicitly fail if some but not all options were specified on the command line, which would also be a breaking change.) If this tool always requires human interaction, we don't need to worry about having an API because we can always assume a human is reading the interactive prompts.

i believe the impl is that any questions not passed a matching CLI param would still be prompted, rather than breaking. so it might be a little less risky

This is a different kind of break in that a previously non-interactive process now requires interactivity.

I do not personally know of a good solution to this (right now) besides asserting SvelteKit's beta nature means that the maintainers should be allowed to change and break things and other people are responsible with keeping up.

[afreidz]

i think the issue lies in deciding whether create-svelte aims to be the sole entry point into sveltekit. or if there is an appetite to have it be consumed by higher order systems. i dont think there is a great solution to support user<>system AND system<>system interactions flawlessly. but i think i would aim to break system<>system patterns over user<>system. i think it would be a fair ask for someone maintaining a system that leverages create-svelte to make regular updates when things break.

[afreidz]

the alternative solution for me is to snapshot the skeleton app and leverage that in my generator. which additionally causes a maintenance point for me to keep in sync with create-svelte. unless svelte were able to maintain a "kitchen sink" sveltekit repo that could be leveraged by create-svelte and/or external systems? i wouldn't mind pruning things from a "yes to all" version of the app based on our desired config.

[afreidz]

anymore thoughts on this or is it effectively NACK'd?

[babichjacob]

i think the issue lies in deciding whether create-svelte aims to be the sole entry point into sveltekit. or if there is an appetite to have it be consumed by higher order systems. i dont think there is a great solution to support user<>system AND system<>system interactions flawlessly. but i think i would aim to break system<>system patterns over user<>system. i think it would be a fair ask for someone maintaining a system that leverages create-svelte to make regular updates when things break.

To be extremely vague, I can imagine create-svelte being broken into a CLI entrypoint and a file that has the actual functionality that the CLI file calls, which lets external sources wrap the create-svelte process without needing to add argument parsing (this PR).

[Conduitry]

Yeah I would definitely favor a purely interactive interface (what we have now) combined with a purely programmatic interface (which would be called from Node) rather than a hybrid CLI-with-command-line-arguments interface. It makes it very clear whether the intended behavior is for it to be interactive or not. And, if we have sensible defaults for all of the options, it lets us add further options without it being a breaking change and without surprising anyone about their automated script suddenly requiring manual interaction.

For the time being, I would like to reserve the right to make breaking changes at any time (until Kit reaches 1.0), but after that I think it's reasonable for the as-yet-unwritten Node API form of create-svelte to follow semver, but not for the interactive CLI version of it to.

[jthegedus]

Coming from #639 - What about each option having a default and defaults being used to answer the questions when a single --defaults flag is present. In my use case I don't really care what the defaults are, I just want to init the template non-interactively. Alternative methods require a lot more work on my end, more work than re-raising this old discussion ;)

Edit: I worked around this in my adapter tests with yes "" | "$(npm init svelte@next app)"