Simplify create-svelte

[Rich-Harris]

Recapping some discussion in Discord prompted by #934:

• our current approach does not scale. the code is already a bit convoluted, New 'Hello World' page #934 makes it more so just by virtue of adding an additional template. if we wanted to add more templates in future, or support (for example) specifying a github repo as a template, things would get out of hand quickly
• i'm of the view, and my sense is that at least most of the core team agree, that encouraging CSS preprocessors like SCSS and LESS is undesirable. they're just not really necessary in a world of scoped component styles and CSS custom properties. if people really want to make their apps more complex by throwing preprocessors at them, they are welcome to do so, but npm init svelte is the wrong place to make that happen
• therefore the only source code modification that needs to happen is TypeScript
• rather than manually writing code that modifies the template, which works in trivial cases but is generally a bit distasteful, we could maintain a TypeScript version of each template and convert it to JavaScript at build time instead (e.g. by running all the .ts files and the <script> of each .svelte file through Sucrase or esbuild)
• there's still some modification that needs to happen to package.json, and there's still some complexity around Prettier and ESLint (the Prettier modifier depends on whether you're using the ESLint modifier, which depends on whether you're using TypeScript) but it's stuff that should in theory be common to all projects, and is therefore immune to the aforementioned scaling issue
• if we're transforming the template code at build time, we don't really need to include the actual template files in the package, we can just create a JSON file with the contents

[Conduitry]

If we're moving away from built-in support for Lass/Sass templates, then #972 is also something we can sidestep, as it would be on users to update their ESLint config accordingly.

[pikeas]

• they're just not really necessary in a world of scoped component styles and CSS custom properties.

They're absolutely vital so long as nesting isn't part of the spec!

[BillyCallahan]

In my opinion nested syntax is a good reason to keep built-in support for Less/Sass. Is there a way to remove it from create-svelte but still make it easily available simply with <style lang='scss'> ?

[babichjacob]

• they're just not really necessary in a world of scoped component styles and CSS custom properties.

They're absolutely vital so long as nesting isn't part of the spec!

Making element styling dependent on nesting has long been known to be a bad idea even to traditional CSS philosophy:

• https://csswizardry.com/2012/05/keep-your-css-selectors-short/
• https://cssguidelin.es/#specificity
• https://medium.com/@verpixelt/your-nesting-is-harmful-a1ffddaf7e43
• https://thesassway.com/avoid-nested-selectors-for-more-modular-css/

And nesting is even less valuable within Svelte components where you can't even nest selectors deeper than what is already in that same file, which I estimate is only about 3-5 levels in most cases.

But even if you disagree, you can still write out your nested selectors explicitly.

A counterpoint is that you might want to style all the various states of a button (hover, active, etc) which isn't the same kind of nesting as previously discussed. But even in that case, writing button:hover, button:active, etc isn't that much more work than button { &:hover { ... } &:active { ... } }.

[babichjacob]

In my opinion nested syntax is a good reason to keep built-in support for Less/Sass. Is there a way to remove it from create-svelte but still make it easily available simply with <style lang='scss'> ?

Install and set up svelte-preprocess and its needed dependencies yourself.

If it's so necessary, someone in the community's probably going to make a Svelte adder for it anyway.