simplify create-svelte

[Rich-Harris]

#987

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

[Rich-Harris]

I think this is a bit simpler — no CSS/SASS/LESS option, and the template (soon to be templates) is authored in TS and converted to JS at build time.

Additionally, the modifiers no longer make brittle edits via code; instead we have files inside directories like

shared/+eslint-prettier

which means 'copy this if the user chose eslint but not prettier, regardless of their typescript choice'. It results in some duplication, but I think it'll prove easier to grok.

Also, since more of the work is happening at build time, the create-svelte package gets even tinier.

Not sure what's going on with the lint failure, will investigation in the morning.

[benmccann]

FYI, lint is failing

The naming scheme seems like it could create an exponential explosion. E.g. we have four eslint configs right now. If we add a prompt for legacy mode (i.e. IE support) that used @babel/eslint-plugin I think we would need to create a +babel and -babel version (or +legacy/-legacy if we want to call it that instead) of each of the existing files so we'd have eight of them. We might be even more likely to hit this for the package.json since it seems likely that any new option might add a dependency

[Rich-Harris]

I hear the point re combinatorial explosion, but my sense is that it's less of an issue than it appears. Firstly, the package.json files are merged (i.e. the eslint and eslint-plugin-svelte3 dev dependencies are only declared in the +eslint directory, not +eslint and +eslint-prettier and +eslint-typescript and +eslint+prettier and +eslint+prettier-typescript and +eslint+prettier+typescript and +eslint+typescript).

I can't imagine us wanting to add a Babel option other than to support a legacy mode, in which case we wouldn't need @babel/eslint-plugin IIUC — that's only to extend the ESLint parser with support for new language features. To my mind that falls very much under 'if you want to add a bunch of complexity to your project, go nuts, but you're on your own'.

In cases where tools don't overlap (i.e. adding Babel without adding the ESLint plugin), no combinatorial explosion will arise; it's just like that right now because TypeScript and Prettier and ESLint do overlap. It certainly could become an issue in future but I think we can probably cross that bridge when we come to it. I still think on balance it's better to have things be declarative even at the cost of some duplication. It's definitely not clear-cut though.

[dummdidumm]

Yeah I'd also say if we add a bunch more stuff and there are too many combinations, we can always revisit this decision. So I'm good with these changes.

[ignatiusmb]

Shouldn't this be at the same level as kit?

Edit: A couple minutes too late :(

[Rich-Harris]

good catch, thanks — fixed in 3c41d07