chore(create-app): update svelte templates

[GrygrFlzr]

• Move from @svitejs/vite-plugin-svelte to @sveltejs/vite-plugin-svelte
  Going forward, this will be the maintained version.
• Adds technical considerations from feat(create-app): add 'svelte' and 'svelte-ts' options #2537 to README files, slightly rewritten for the user.
• Remove unnecessary complexity from store.
• Move globals.d.ts to src/global.d.ts to match SvelteKit (and iirc global.d.ts is the more common name).
• Get rid of the import.meta.hot usage, turns out normal external stores work fine across HMR updates.
• Change the cursor when its over the button.

[patak-dev]

@antfu we already discussed this with @GrygrFlzr in Discord, and I tested both templates locally. I think we can merge after your review.

[patak-dev]

Though: it is interesting that the Svelte plugin will live out of Vite's monorepo while the Vue and React plugins live in Vite's monorepo. I don't think it is bad since it is good that the Svelte team can modify the plugin without going through Vite's PR process. Maybe at one point in the future, the Vue and React plugins may also end up being maintained in separated repositories.

[bluwy]

Would it be best if we only export a counter store? This might probably break HMR, but it's weird to have this pattern in the starter template.

Or we can also simplify this and have a normal count variable in Counter.svelte with // @hmr:keep per rixo's idea in Vite Land?

[dominikg]

this getStore function originated from a playground in svite where i used it for testing purposes. I think it is overkill in a minimal starter template and may not even be a good idea in production use in general.

+1 for a more simple solution

[GrygrFlzr]

From what I can tell our options are:

1. straight up an external writable() store with no id:

   import { writable } from "svelte/store";
   export default writable(0);

   State is preserved across all updates except to store.js itself, which is intuitive, but also doesn't reflect how people use local state in components.
2. // @hmr:keep on the single counter variable
3. // @hmr:keep-all on the component
4. preserveLocalState in vite.config.js - but this was disabled by default for a reason.

With options 2-4, state is lost upon updating App.svelte, as the Counter component is recreated. We're just picking which flavor of poison to go with.

Thoughts @dominikg @rixo?

[GrygrFlzr]

I discussed this further with dominik over Discord and decided on a fifth option: the default of no local state preservation. The crux of the issue is that its complicated enough to hide behind flags, so like @sveltejs/kit it's likely best to keep disabled, and the behavior can be explained in the README.

[rixo]

I strongly believe we should go with option 2. It sidesteps most difficulties, and hints just the right amount of information to maximize people's understanding and learnability.

Enabling preserveLocalState by default goes against the grain of "no friction HMR", I believe, because its behaviour is hard to anticipate and predict intuitively. Because of this, it makes HMR feel more fragile and unreliable than it actually is, hence lessening its value for the user (HMR value is all about being confident that your change are reflected the same way they would be without it, any glitch or unpredictability eats hard into this confidence). Furthermore, the difficulties created by preservation of state are all but exacerbated in Svelte, since any random let variable is a piece of state in Svelte components.

Stores sure are cool and all, but I don't think they have much to do with HMR at this point. State existing in other modules that are not traversed by a HMR bubble is always preserved (otherwise that wouldn't be HMR). Also, there's little doubt that a user of Svelte will soon enough be exposed to lot of documentation and information about them. As such, HMR-wise, I'm pretty neuter to have them or not to have them in a starter example.

On the contrary, most people will never read any bit of HMR docs (we don't want them to have to), and so illustrating that the capacity (preserving local state) exists, and demonstrating the existence of the // @hmr-keep comment is probably the best we can achieve. It non-obstructively hints people about the situation, giving them some hook for something to search about, if they're so inclined.

Other magic HMR comments like // @hmr:keep-all are kinda out of scope for a starter, to me... People will find about them, googling for // @hmr:keep, if they're interested into it. Otherwise, they're not so useful I guess. And HMR is not about HMR, it's about a nice dev experience, and so less docs / information / noise about it is probably the better.

[rixo]

@GrygrFlzr To be clear, my last comment was started and sent before your last one, that I just discover. I still personally believe having the behaviour and magic comment trick illustrated rather than documented would probably be the best trade off, but I'm rather good with any direction this can take, except for enabling preserveLocalState by default. This one has really proven confusing and detrimental to the HMR experience in the past, and I much more prefer having the occasional user that is disappointed not to have their counter keep its value, which is really a minor inconvenience, than risking to feed and grow a general sentiment of "yet another broken HMR".

[dominikg]

I'd love to see this merged rather sooner than later.
A deprecation warning has been added to @svitejs/vite-plugin-svelte , asking users to update to @sveltejs/vite-plugin-svelte