Support multiple compiler & preprocess options

[milkbump]

This is a reiteration of sveltejs/language-tools#410 but in the context of svelte-kit.

Is your feature request related to a problem? Please describe.
Currently, the svelte.config.js assumes one config for your entire directory. However, it's not uncommon to want to compile some components to web component and others to vanilla Svelte. Some components may need one CSS, Markdown, Language (TS)...etc. preprocess and others another one, especially when using an external Svelte library.

Describe the solution you'd like
When using Rollup, I solve this using the exclude/include options and multiple instances of the Svelte plugin. (Not very elegant)

// rollup.config.js
import svelte from "rollup-plugin-svelte";


const WEB_COMPONENT_POSTFIX = `**/*.wc.svelte`
// Omitted for brevity
// const TS_COMPONENT_POSTFIX = "**/*.ts.svelte";
// const DOC_COMPONENT_POSTFIX = "**/*.doc.svelte"; // preprocessed for MdSvex etc.

export default {
    ...
    svelte({
        preprocess: regularSveltePreprocess,
        exclude: WEB_COMPONENT_POSTFIX,
    }),
    svelte({
        customElement: true,
        preprocess: webComponentPreprocess,
        include: WEB_COMPONENT_POSTFIX,
    }),
    ...
}

My current suggestion is to accept an array of compilerOptions and preprocessOptions.

// svelte.config.cjs

// set up `webComponentsPreprocess` && `vanillaPreprocess`
module.exports = {
	  preprocess: [
		    {
		       preprocess: webComponentsPreprocess,
		       include: "**/*.wc.svelte",
		    },
		    {
		       preprocess: vanillaPreprocess,
		       include: "**/*.svelte",
		       exclude: ["**/*.wc.svelte", "**/*.ts.svelte"],
		    }
	  ],
	  compilerOptions: [
		{...},
		{...}
	 ]
},

Describe alternatives you've considered
I haven't found an alternative in the context of the svelte-kit. Suggestion for workarounds are welcome.

How important is this feature to you?
This is critical to different projects I work on, (particularly those using some web components and an external Svelte component library). It's a blocker to migrating from Rollup.

Additional context
The solution implementation for this issue would be far-reaching. It may need some consensus from several Svelte tools using svelte.config.cjs.

[Rich-Harris]

I think these are are all solvable without changing the design:

Some components may need one CSS, Markdown, Language (TS)...etc. preprocess

Preprocessors typically target specific languages, identified with lang="ts" etc. If those attributes are absent, the preprocessor is a no-op. Preprocessors also have access to the filename, so e.g. a .svelte.md file could have markdown processing applied while a .svelte file doesn't.

especially when using an external Svelte library

Libraries shouldn't require preprocessing, they should be distributed in a ready-to-use state.

it's not uncommon to want to compile some components to web component and others to vanilla Svelte

This is perhaps a little trickier. I'd definitely push back on 'it's not uncommon' :) but this is possibly a case where you could create a separate library of WCs and import them after they've been built:

<script>
  import '@me/my-wcs/my-widget'
</script>

<my-widget answer={42}/>

[milkbump]

All these are helpful. I'll see how far I can get with some of them. They're just sometimes a bit inconvenient.

Preprocessors typically target specific languages, identified with lang="ts" etc. If those attributes are absent, the preprocessor is a no-op. Preprocessors also have access to the filename, so e.g. a .svelte.md file could have markdown processing applied while a .svelte file doesn't.

I suppose it's straight forward to write a preprocessor for such use cases, but with the added inconvenience of separately maintaining some functionality included out of the box in svelte-preprocess.

Libraries shouldn't require preprocessing, they should be distributed in a ready-to-use state.

Suppose I have TypeScript or Sass in my library, and I don't expect downstream users to have TS or Sass in their setup, is there a canonical way to preprocess, but not compile svelte components for distribution?

The alternative is to say that libraries simply can't use any preprocessing or non-default compiler settings.

What about a situation when the user's components have preprocessing that they don't want to affect library's "non-preprocessing"? It goes back to the above svelte-preprocess inconvenience to filter out the library's components in a custom preprocess block.

you could create a separate library of WCs.

Again, this is workable, but the ergonomics of separate build steps is not ideal if it can be avoided.

[dummdidumm]

Libraries shouldn't require preprocessing, they should be distributed in a ready-to-use state.

Suppose I have TypeScript or Sass in my library, and I don't expect downstream users to have TS or Sass in their setup, is there a canonical way to preprocess, but not compile svelte components for distribution?

Unfortunately not yet. There are some related discussions in the componente-template (1, 2, 3).

[Rich-Harris]

I suppose it's straight forward to write a preprocessor for such use cases, but with the added inconvenience of separately maintaining some functionality included out of the box in svelte-preprocess.

I'm not sure I understand — svelte-preprocess already does this. What functionality needs to be maintained separately?

is there a canonical way to preprocess, but not compile svelte components for distribution?

There will be! It will be a part of SvelteKit (the component-template repo will almost certainly be archived). In the meantime it's possible to do it yourself just by using the preprocess API manually.

[dominikg]

vite-plugin-svelte supports the same include/exclude options as rollup-plugin-svelte https://github.com/sveltejs/vite-plugin-svelte/blob/b229a8c412db713663021cf9d20bb179f0d42cbd/packages/vite-plugin-svelte/src/utils/options.ts#L140.

If you pass preprocessors as inline options you should be able to recreate the rollup config in the original post.

[benmccann]

It sounds to me like this was addressed by dominikg's comment, so I'm going to go ahead and close this