Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description 📖
This pull request fixes a compatibility issue between
vite-plugin-svelte
and backend integrations like Vite Ruby, by using theroot
provided by Vite in theconfigResolved
hook.Background 📜
vite-plugin-svelte
needs to infer theroot
beforeconfigResolved
in order to pre-scan svelte dependencies, which was last changed in #115.Vite plugins can override options using the
config
hook. In particular, Vite Ruby changes theroot
option based on user configuration, which is typically a subfolder (instead of the project root,process.cwd()
).vite-plugin-svelte
does not use the resolved value forroot
, which can cause Vite andvite-plugin-svelte
to use different values ofroot
to resolve paths.The Bug 🐞
Since the
root
is different, the check for file existence when creating a CSS virtual module no longer matches the expected result, preventing CSS virtual modules from being served.Proposed Fix 🔨
Using the
root
that Vite provides in theconfigResolved
hook fixes this and other similar problems.Notes ✏️
Since
vite-plugin-svelte
usesenforce: 'pre'
, it's not viable for other plugins to workaround this issue without this patch.Using
enforce: 'pre'
in other plugins would make the outcome dependent on the order in which the plugins are applied in the user config, which would be error-prone and result in a bad user experience.