-
-
Notifications
You must be signed in to change notification settings - Fork 6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(create-app): add 'svelte' and 'svelte-ts' options #2537
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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 ?
There's currently an open issue (sveltejs/kit#497) regarding whether we'll end up using |
Adds
svelte
andsvelte-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?
vite dev
andvite 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 ofcompilerOptions.types
insidejsconfig.json
ortsconfig.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 addingsvelte
andvite/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 forcecheckJs: 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.