|
| 1 | +# Svelte + TS + Vite |
| 2 | + |
| 3 | +This template should help get you started developing with Svelte and TypeScript in Vite. |
| 4 | + |
| 5 | +## Recommended IDE Setup |
| 6 | + |
| 7 | +[VS Code](https://code.visualstudio.com/) + [Svelte](https://marketplace.visualstudio.com/items?itemName=svelte.svelte-vscode). |
| 8 | + |
| 9 | +## Need an official Svelte framework? |
| 10 | + |
| 11 | +Check out [SvelteKit](https://github.com/sveltejs/kit#readme), which is also powered by Vite. Deploy anywhere with its serverless-first approach and adapt to various platforms, with out of the box support for TypeScript, SCSS, and Less, and easily-added support for mdsvex, GraphQL, PostCSS, Tailwind CSS, and more. |
| 12 | + |
| 13 | +## Technical considerations |
| 14 | + |
| 15 | +**Why use this over SvelteKit?** |
| 16 | + |
| 17 | +- It brings its own routing solution which might not be preferable for some users. |
| 18 | +- It is first and foremost a framework that just happens to use Vite under the hood, not a Vite app. |
| 19 | + `vite dev` and `vite build` wouldn't work in a SvelteKit environment, for example. |
| 20 | + |
| 21 | +This template contains as little as possible to get started with Vite + TypeScript + Svelte, while taking into account the developer experience with regards to HMR and intellisense. It demonstrates capabilities on par with the other `create-vite` templates and is a good starting point for beginners dipping their toes into a Vite + Svelte project. |
| 22 | + |
| 23 | +Should you 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. |
| 24 | + |
| 25 | +**Why `global.d.ts` instead of `compilerOptions.types` inside `jsconfig.json` or `tsconfig.json`?** |
| 26 | + |
| 27 | +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. |
| 28 | + |
| 29 | +**Why include `.vscode/extensions.json`?** |
| 30 | + |
| 31 | +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. |
| 32 | + |
| 33 | +**Why enable `allowJs` in the TS template?** |
| 34 | + |
| 35 | +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 worst of both worlds: not being able to guarantee the entire codebase is TypeScript, and also having worse typechecking for the existing JavaScript. In addition, there are valid use cases in which a mixed codebase may be relevant. |
| 36 | + |
| 37 | +**Why is HMR not preserving my local component state?** |
| 38 | + |
| 39 | +HMR state preservation comes with a number of gotchas! It has been disabled by default in both `svelte-hmr` and `@sveltejs/vite-plugin-svelte` due to its often surprising behavior. You can read the details [here](https://github.com/rixo/svelte-hmr#svelte-hmr). |
| 40 | + |
| 41 | +If you have state that's important to retain within a component, consider creating an external store which would not be replaced by HMR. |
| 42 | + |
| 43 | +```ts |
| 44 | +// store.ts |
| 45 | +// An extremely simple external store |
| 46 | +import { writable } from 'svelte/store' |
| 47 | +export default writable(0) |
| 48 | +``` |
0 commit comments