feat(create-app): add 'svelte' and 'svelte-ts' options

[GrygrFlzr]

Adds svelte and svelte-ts templates.

Why Svelte?

I believe there is interest in having Svelte as a first-class create-app template, based from previously opened issues (#2209) and prior communication with Vite maintainers in the official Discord server.

Why not SvelteKit?

• It's currently still pre-alpha.
• It currently does not support the pure-SPA use case.
• It brings its own routing solution which might not be preferable for some users.
• It is first and foremost a framework that just happens to use Vite under the hood, not a Vite app.
  vite dev and vite build wouldn't work in a SvelteKit environment, for example.

The templates in this PR contain as little as possible to get started with Vite + Svelte, while taking into account the developer experience with regards to HMR and intellisense. It demonstrates capabilities on par with the other create-app templates and is a good starting point for beginners dipping their toes into a Vite + Svelte project.

Should they later need the extended capabilities and extensibility provided by SvelteKit, the template has been structured similarly to SvelteKit so that it is easy to migrate.

Technical considerations

Why globals.d.ts instead of compilerOptions.types inside jsconfig.json or tsconfig.json?

Setting compilerOptions.types shuts out all other types not explicitly listed in the configuration. Using triple-slash references keeps the default TypeScript setting of accepting type information from the entire workspace, while also adding svelte and vite/client type information.

Why include .vscode/extensions.json?

Other templates indirectly recommend extensions via the README, but this file allows VS Code to prompt the user to install the recommended extension upon opening the project.

Why enable checkJs in the JS template?

I believe most cases of changing the types of variables in runtime are likely to be accidental, rather than deliberate. This provides advanced typechecking out of the box. Should the user like to take advantage of the dynamically-typed nature of JavaScript, it is trivial to change the configuration.

Why enable allowJs in the TS template?

While allowJs: false would indeed prevent the use of .js files in the project, it does not prevent the use of JavaScript syntax in .svelte files. In addition, it would force checkJs: false, bringing the user the worst of both worlds: not being able to guarantee their entire codebase is TypeScript, and also having worse typechecking for the existing JavaScript. In addition, I believe there are valid use cases in which a mixed codebase may be relevant.

Why include an HMR store, instead of just using local state?

This allows us to take full advantage of HMR. While vite-plugin-svelte does support an option to enable local state saving, it is not recommended, as it is an inherently difficult problem to solve without external stores. Changes to the local state definition can make it unclear what the intended HMR behavior is. Admittedly, the code is a bit more advanced and takes advantage of some frameworky features of Vite, but I believe this is a better out-of-the-box experience and does not add unnecessary complexity.

[patak-dev]

Looks great! Just tested and they worked like a charm.
Thanks for the detailed explanation.

Once SvelteKit is released, is the idea to move from @svitejs/vite-plugin-svelte to https://github.com/sveltejs/kit/tree/master/packages/vite-plugin-svelte ?

[GrygrFlzr]

@svitejs/vite-plugin-svelte is the maintained one and has better type information. SvelteKit also uses that one.

There's currently an open issue (sveltejs/kit#497) regarding whether we'll end up using@svitejs/vite-plugin-svelte or @sveltejs/vite-plugin-svelte, or which monorepo it should be on (or even an external repository), but both are drop-in replacements of each other. Should the module be moved it's pretty much just a change to package.json.