hmr does not work for dependencies returned from svelte-preprocess

Description

During svelte-preprocess, additional dependencies can be encountered and are returned as an array. Changes to these files currently do not trigger the expected hot module reload during vite dev

Reproduction

use one of the many ways to define an additional dependency by referencing a file in a svelte component that is then preprocessed. eg

<style lang="scss" src="./extra-file.scss"></style>

Additional Information

original bugreport on sveltekit: https://github.com/sveltejs/kit/issues/849

Things to do

1. ensure the dependencies are watched correctly. For most files this should already be the case as they are inside the vite root. Call ‘addWatchFile’ anyways.
2. ensure that edits to these files trigger hmr update

• either by adding the files as dependencies to the respective js/css module of the .svelte file on the moduleGraph
• or by triggering an update event on the svelte file manually

[dominikg]

As vites importAnalysis plugin prevents us from manipulating the module graph to add the dependencies here’s an alternative approach: https://github.com/sveltejs/vite-plugin-svelte/tree/fix/watch-preprocessor-dependencies

preprocess dependencies are watched for changes and when they are changed, it triggers a change event on the parent svelte component file so standard vite handleHotUpdate mechanism runs.

https://github.com/sveltejs/vite-plugin-svelte/blob/80d448eecd13ebc69f180f0bb330a127c365e8e9/packages/vite-plugin-svelte/src/utils/preprocess.ts#L110

Tracking of dependencies/dependants is done via the compile cache

Initial tests look good: https://github.com/sveltejs/vite-plugin-svelte/blob/fix/watch-preprocessor-dependencies/packages/playground/svelte-preprocess/__tests__/svelte-preprocess.spec.ts

Thoughts?

[rixo]

Tracking config files isn’t worth it. There’s so many possible cases – all of them soon expanding to .mjs, .cjs, etc – that would be a promise we cannot fully deliver, scoring at best something between deceive and disappoint, depending on user setup. Furthermore, it’s something nobody really expects, in a cold path with no high returns even if it worked… And, all in all, far more easier to handle in userland with restart plugin + I know what config files I’m actually using in my project (even that seems too much trouble to me).

The initial point of the issue, tracking code dependencies, in the hot path, is what really matters IMO.