notes from adding support in vite-plugin-svelte

[dominikg]

I've started working on adding support for rolldown-vite in vite-plugin-svelte. In this thread i'll post some notes/findings that might help improving rolldown-vite/rolldown and other plugin authors to improve their plugins.

main PR here: sveltejs/vite-plugin-svelte#1135

[dominikg]

new filter syntax

filtering in rollup plugins works with javascript, as such vite-plugin-svelte used rollup/pluginutils to create a filter function from user-provided include/exclude patterns. It combined include with a list of extensions with AND.

The way the new hook filters work include values are combined with OR, leading to a breaking change in the plugin behavior. This is probably ok as custom include was a rarely used feature and users can resort to either using include patterns that also have extensions or exclude patterns to filter files they don't want to pass through.

PR: sveltejs/vite-plugin-svelte#1132

Another notable thing is that vite-plugin-svelte (similar to plugin-vue) uses query params as hints, eg App.svelte?svelte&type=style&lang.css for its virtual style modules.

Constructing regexes for include filters to match file extensions is a bit cumbersome, i ended up using a regex like

/^[^#?]+\.(?:svelte|svx)(?:[?#]|$)/ to ensure the extensions are only matched at the end of the string or immediately before first # or ? - technically # is a character that can occur in filenames but historically vite was never able to deal with these well so not a big deal here

[TheAlexLichter]

There are helpers via @rolldown/pluginutils which should help with constructing regexes (rolldown/rolldown#4458), even though there is none for file extensions (not sure how common that case is though, if it is, we might want to consider adding a helper there)

[dominikg]

i saw rolldown/pluginutils but the filter utils in particular didn't come with examples and i couldn't easily figure out how to make them work with multiple extensions and matching both at end of string or in front of first ? or #.

If you have examples of that that would be great.

[sapphi-red]

I guess makeIdFiltersToMatchWithQuery is similar to what you are looking for (it doesn't handle # though).
I've added an example jsdoc in rolldown/rolldown#4915.

[dominikg]

transformWithESBuild -> transformWithOxc

sveltejs/vite-plugin-svelte@e708199#diff-adaa2dab00c8f53786ed4735038587611afb6985af2046607d7bdf5ebbfc6f1cR81

transformWithESBuild allowed passing in tsconfigRaw via esbuild options, which vite-plugin-svelte used to enforce 2 values required for svelte component imports.

transformWithOxc reads from tsconfig and expects these values to be present in user config. This is the case in @tsconfig/svelte and should be set for most users, but is technically a breaking change for vitePreprocess as that previously worked without a matching tsconfig due to the builtin tsconfigRaw.

[sapphi-red]

Maybe we can receive tsconfigRaw option here as options?: OxcTransformOptions & { tsconfigRaw?: TSConfigJSON } and

rolldown-vite/packages/vite/src/node/plugins/oxc.ts

Line 60 in bf84ccb

options?: OxcTransformOptions,

merge it with the loaded one here.

rolldown-vite/packages/vite/src/node/plugins/oxc.ts

Line 98 in bf84ccb

const loadedCompilerOptions = loadedTsconfig.compilerOptions ?? {}

[dominikg]

If you think it is good as a general use case that would be nice, however i am fine with this particular break as it should only affect projects that are missing a tsconfig in this case. We can wait until a beta of vite-plugin-svelte is out and some actual user complaints come in that are not remedied by adding a tsconfig.

[dominikg]

rollup vs rolldown

treeshaking/dead code removal in rolldown is not on the same level as rollups, leading to compatibility issues with some svelte features for serverside bundles rolldown/rolldown#3403

[TheAlexLichter]

Agreed, DCE is still work in progress to be on par. We have a few issues in the repo (and more upstream) that cover future improvements, including #155 and #196 (comment)

[dominikg]

also related #229

[dominikg]

comparing build output of vite and rolldown-vite with svelte, it appears that rolldown-vite does not remove unreachable code paths guarded by if(false)

output with vite7+rollup

function effect_in_teardown(rune) {
	{
		throw new Error(`https://svelte.dev/e/effect_in_teardown`);
	}
}

same with rolldown-vite (vite 6.3.19+rolldown 1.0.0-beta.15)

function effect_in_teardown(rune) {
	if (false_default) {
		const error = new Error(`effect_in_teardown\n\`${rune}\` cannot be used inside an effect cleanup function\nhttps://svelte.dev/e/effect_in_teardown`);
		error.name = "Svelte error";
		throw error;
	} else throw new Error(`https://svelte.dev/e/effect_in_teardown`);
}

[TheAlexLichter]

And false_default is just a const false_default = false I assume?

because if(false) branches should eliminate but not with a const. This should be rolldown/rolldown#4258

[dominikg]

optimizer plugins

in vtes esbuild optimizer, vite-plugin-svelte injects a custom esbuild plugin to transform .svelte files in node_modules during optimize. Vite's scanner can scan .svelte files on its own, but for the actual transform a plugin is needed.

esbuild implementation here: https://github.com/sveltejs/vite-plugin-svelte/blob/f02083d77859d9c602fb462b87f1c06a9a770867/packages/vite-plugin-svelte/src/utils/esbuild.js#L20

(note: due to vite-plugin-svelte reading svelte config, the plugin isn't statically configured but rather a placeholder is added in config hook that is later updated with Object.assign)

unfortunately i havn't found a way to identify the scanner phase yet or a way to disable a svelte optimizer plugin during it. Neither code exclude filters work nor does the plugin context contain environment information in the hooks that are called (buildStart/transform).
this.meta is

{
  "rollupVersion": "4.23.0",
  "rolldownVersion": "1.0.0-beta.11-commit.0a985f3",
  "watchMode": false
}

[sapphi-red]

options hook should have been called for the scanner but wasn't called. I've just fixed that (rolldown/rolldown#4911). This should allow plugins the detect whether it's running in the scanner by the same way with the esbuild plugins did (build.initialOptions.plugins?.some((v) => v.name === 'vite:dep-scan')).

[dominikg]

detect whether it's running in the scanner by the same way with the esbuild plugins did (build.initialOptions.plugins?.some((v) => v.name === 'vite:dep-scan')).

due to how esbuild constucts plugins, our detection prevented it from running at all. What would be the equivalent in rolldown options hook and where do you get the ref to build.initialOptions ?

https://rollupjs.org/plugin-development/#options

best guess i have is

const plugin = {
  name: 'some-optimizer-plugin',
  options(opts) {
    if(opts.plugins?.some(p => p.name==='vite:dep-scan'){
      plugin.transform.filter.id.include=[/^$/]; // A include only empty id, should include nothing?
      plugin.transform.filter.id.exclude=[/./]; // B or exclude any id of at least one char matching .
      plugin.transform.handler=()=>{}; // C set handler to noop 
    }
  },
  transform:{
    filter:{id:include:[/\.ext(?:\?|$)/]}.
    handler(code,id){
      //...
    } 
  } 
}

but ideally it would be sth like

const plugin = {
  name: 'some-optimizer-plugin',
  applyToEnvironment(env) {
    return env.name==='optimize' // scan env and optimize env are different, right?
  }
  //...

maybe i'm missing some context still but i would have expected optimizer plugins to be closer to vite plugins than pure rolldown plugins

[sapphi-red]

probably like

const plugin = {
  name: 'some-optimizer-plugin',
  options(opts) {
    // by the way, it probably has to check vite:dep-scan:resolve
    if(opts.plugins?.some(p => p.name==='vite:dep-scan:resolve'){
      delete plugin.resolve
      delete plugin.load
      delete plugin.transform
    } else {
      plugin.resolve = { /* ... */}
      plugin.load = { /* ... */}
      plugin.transform = { /* ... */}
    }
  }
}

We can have something like applyToEnvironment, but that would only work for svelte plugin's case (code search). To do that, we first need to introduce optimizer environment (we have scanner environment but don't have optimizer environment).

[dominikg]

removing/readding hooks in options hook works for now, it would be nice to have a more official way to differenciate between scanner & optimizer though. esp as long as vites internal scanner treats some extensions (long term it might be better to not have that in core, but maybe that whole problem goes away with bundled dev mode?)

[dominikg]

typing things

with vite and rolldown-vite having some type differences, notably addtions for rolldown-vite, eg optimizeDeps.rollupOptions it can be hard to type things correctly because you can't know if the user overrides vite or not.

Adding rolldown-vite as a devDependency and then selectively importing types from there should work but some types from rolldown-vite are not exposed which makes working with eg optimizeDeps.rollupOptions.plugins a bit harder.

[sapphi-red]

Which types specifically are not exposed? Does import type * as vite from 'rolldown-vite'; vite.Rolldown contain some types you need?

[dominikg]

Which types specifically are not exposed? Does import type * as vite from 'rolldown-vite'; vite.Rolldown contain some types you need?

optimizeDeps.rollupOptions.plugins doesn't work here https://github.com/sveltejs/vite-plugin-svelte/pull/1135/files#r2140165974

(edit: even when adding rolldown-vite to devDependencies and changing the type import)

[dominikg]

using types exposed through vite.Rollup solved these in vite-plugin-svelte