Closed dominikg closed 7 months ago
Just looking at this, we need to possibly avoid some other call-sites for Svelte 5:
svelte-hmr
and it's not even compatible with Svelte 5. Same for this line https://github.com/sveltejs/vite-plugin-svelte/blob/main/packages/vite-plugin-svelte/src/utils/compile.js#L168the goal is that we have a new compile option for svelte5 like compileOptions.hmr, and don't use vitePlugin.hot at all anymore. It being forced to false leads to svelte-hmr being unused so we don't need all of the code for that anymore..
Which brings us to the next step that follows around rc release of svelte5, a new vite plugin svelte major that removes all of the code only required for svelte4, including removal of svelte-hmr as a dep. This would also allow us to introduce svelte5 specific hmr handling in v-p-s but ideally we just pass the option through so that other bundler plugins can reuse it. For my current point of view import.meta.hot by vite is the closest thing to a standard we have in that area and any new bundlers/implementations for it would probably be based on that.
@rixo knows more about the history between divergences in snowpack, vite and nollup.
potentially different apis would be webpack https://webpack.js.org/api/hot-module-replacement/ and turbopack ?! the question is if you want to deal with these on the compiler level or if you want the bundler plugin to give you an adapter like svelte-hmr did in createMakeHot?
this early return needs to be changed in this PR before it actually works https://github.com/sveltejs/vite-plugin-svelte/blob/8ae3dc8cf415355f406f23d6104cb6153d75dfc8/packages/vite-plugin-svelte/src/index.js#L182
do we have to check a minimum svelte5 version to avoid it breaking for users on previous alphas?
@dominikg If they are on previous alphas, compilerOptions.hmr
will just say the option isn't supported, prompting them to update.
enable support for the upcoming native hmr support in svelte5
cc @rixo