Glob pattern support for different Svelte files in svelte.config.js

[milkbump]

Is your feature request related to a problem? Please describe.
Currently, the svelte.config.js assumes one config for your entire directory. However, I'd like to have some Typescript, Web Component and Vanilla-Svelte™ files in the same directory.

If I use config for TS only, I get warnings outside of TS Svelte, and <svelte:option tag/> warnings for web components and vice versa.

For rollup, I use a config that looks like this using exclude & include:

// 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}`,
    }),
    ...
}

Describe the solution you'd like
I'd like to be able to use different pre-process options for different glob patterns

// svelte.config.js

// set up `webComponentsPreprocess` && `vanillaPreprocess`

export default [
    {
       preprocess: webComponentsPreprocess,
       include: "**/*.wc.svelte",
    },
    {
       preprocess: vanillaPreprocess,
       include: "**/*.svelte",
       exclude: ["**/*.wc.svelte", "**/*.ts.svelte"],
    }
],

Describe alternatives you've considered
Store files in a different directory based on compile target/pre-process needs. However, this is an anti-pattern. For example, I might have a web component with regular Svelte components as children using the above pattern. Storing strongly related files separately is not preferred.

Additional context
This is particularly helpful for using the exclude && include pattern in other tools like Svite that depend on svelte.config.js for configuration.

[dummdidumm]

I'm a little against this. Doing this might want to have people even more options for filtering. Also, you can already do the same with preprocessors as they are now.
Each file that is handed to preprocessors also passes its filename, so you can just wrap your preprocessors with another preprocessor deciding which one to invoke based on the file path. Like this:

const preprocessor = {
  markup: ({filename, content}) => {
    if (isInPathX(filename)) {
       return vanillaPreprocess.markup(..)
    } else ...
   , ...
}

[milkbump]

For pre-processing, your suggestion addresses some of my needs. However, for the compilerOptions (e.g customElements etc.) I don't see how to choose an option dynamically based on the filename.

That said, if everyone has their own way of including and excluding, and pre-processing files then tools can't make predictable assumptions about your config setup. For example, @dominikg just assumes the typescript preprocessor is the first one, which would fail if I used your suggested filtering method.

We need to standardize how we tell Svelte tools where to find our typescript files, web components and whatever pre-processable next language/tool will be. Improvements to my suggestion are welcome, but I don't think having varied implementations for config is the solution. See Rich Harris' comment on svelte.config.js.

Where people asking for filtering (and other options) is concerned, we should just address them on a case by case basis. As rule of thumb though, I suggest mostly preferring options that are widely implemented in other bundlers and configs —such as filtering based on filename/extension.

Edit: Svench is another example of a tool using .svench/.svench.svelte extensions that would benefit from a standard svelte.config.js for excluding/including files.

[milkbump]

Another caveat worth discussion is that Svite, for example, only respects the svelte.config.js at the root of your project, while the language server uses a different svelte.config.js for each directory if available using cosmiconfig.

Having different svelte.config.js files to handle dynamic configuration gets unwieldy fast and is harder to debug. It's easier for developers and tooling if all the dynamicity is handled in one file, at the root of your project. My suggestion is one solution that enables this.

[dominikg]

I think sveltejs/svelte#1101 (or a separate issue on sveltejs/svelte) is a better place to have this discussion as both language-tools and svite are consumers of svelte.config.js

Personal opinion: This is a very complicated feature and should only be pursued if this is of general interest to the community.

From what i understand it boils down to the ability of having multiple named configs, either via separate files or as an array/map in svelte.config.js to be able to process subsets of a project with different svelte configs.
This needs to be supported by all tooling dependant on svelte.config.js and thats a lot of work, including adding support for svelte.config.js to rollup-plugin-svelte, which does not exist today (svite feeds content of svelte.config.js to it after some processing).

Regarding svite only reading svelte.config.js from cwd: Svite used to use cosmiconfig, but cosmiconfig also reads from package.json "svelte" key by default which is used for something different in svelte-land. To avoid errors and get rid of the dependency I removed that feature.
This should also be part of the definition of svelte.config.js "contract". Is it a single file that affects the whole project or should there be a 'resolver' that finds the first parent svelte.config.js and use that. Another complicated thing which properbly requires a 'svelte-config' package just so that all tools can use it and not reimplement resolving all over.

[dummdidumm]

Closing this because @dominikg is right, this should be discussed in the original issue.