svelte.config.js

[Rich-Harris]

Just spotted this issue: DeMoorJasper/parcel-plugin-svelte#6

I'm not wild about the idea of introducing another config file into people's projects, but if folks are going to start doing it, then there should probably be a canonical, officially supported form.

(This, incidentally, is why the current 'zero-config' marketing fad is such nonsense: it really means 'abdicate the responsibility for config'. Instead of a single place where you can view all the build config in a structured, coherent form, you have the exact same amount of config but scattered around your project in lots of annoying files that are harder to understand.)

Other plugins like rollup-plugin-svelte and svelte-loader — and the CLI — could also load svelte.config.js. (We'd have to figure out the semantics — do the options in rollup.config.js or webpack.config.js override svelte.config.js, or extend them? Also, what happens if you have svelte.client.config.js and svelte.server.config.js? How do you reference them?)

Clearly this introduces some regrettable complexity. One advantage we'd get in return would be that documentation becomes clearer — rather than explaining 'oh, you need to add this to the option you pass to rollup-plugin-svelte, or maybe svelte-loader, or...' we can just say 'this is what you put in your config file'.

Is this the zero-config tail wagging the dog? Or would this be a worthwhile addition?

[vjeux]

@Rich-Harris I've been trying to hold off on config files for as long as possible with prettier but the result was that all the tools that were built on-top of prettier built their own incompatible way of dealing with prettier options. So this was a net negative.

cosmiconfig is a really nice tool to deal with reading the config in all the possible places and format.

[tivac]

👍 to cosmicconfig being good!

[Rich-Harris]

Oh wow, cosmiconfig is really helpful to know about, thank you @vjeux! Hadn't come across it before.

[TheLarkInn]

On the fence, but if it simplifies the svelte-loader code, I would say sure why not.

[DorianGrey]

Officially supporting a config file - whatever it is named - might simplify every bundler integration since it removes the need of providing the config via each particular bundler, with the downside of having to provide that additional config file in case the defaults do not match to the particular requirements.

Just a note: While cosmiconfig supports several different config file formats, providing a config for preprocess requires functions and thus would only be available in the .config.js version.

[ansarizafar]

There should be a single config file with keys for server, client, compilerOptions, serviceWorker etc.

[jamesbirtles]

Going to need something like this for the language server I'm working on.

Would be great to standardise this sooner rather than later

[jamesbirtles]

Btw, svelte-language-server is using cosmiconfig to load config for svelte

[kaisermann]

I'm a fan of cosmiconfig, but it will conflict with the svelte property on components package.json wit the default config (maybe rename it to svelte:component or something alike...)

(@UnwrittenFun thanks for the vscode extension!)

[PaulMaly]

Hi! So, what’s in the end an official way to provide shared config?

[kaisermann]

Just an update about my cosmiconfig comment: the lib is practical but it's h-e-a-v-y. It weighs 44kb gzipped alone thanks to js-yaml 😢.

I think supporting just svelte.config.js would be a beginning.

This is something that comes up a lot on svelte-preprocess and svelte-vscode issues. A lot of people struggle to configure their environment without getting errors about expected selector and other similarities. Maybe just some documentation about how to make a shared config (which is nothing more than a require('./svelte.config.js') in many cases) would also help.

[dominikg]

bump.
We had a small discussion about the content of svelte.config.js on svelte discord #language-tools

dummdidumm suggested the following structure

{
  compilerOptions: {...svelte's compiler options}, 
  ...anythingelse 
}

I think it would be great to have a common configuration for different tools in the svelte ecosystem.

[jthegedus]

There's also an RFC for a sapper.config.js file which references/caters for the svelte.config.js currently in use by svelte/language-tools.

[dummdidumm]

Both svite and svelte-language-tools / Svelte for VSCode now adhere to the proposal @dominikg mentioned.

It should be noted that svelte-language-tools expects the preprocessor to be set within preprocess, which might be another thing for standardization:

{
   compilerOptions: { ... },
   preprocess: ...,
   ...anything else
}

[milkbump]

I'd like to suggest further improvements that make svelte.config.js more versatile detailed in sveltejs/language-tools#410.

[Rich-Harris]

I regret not paying closer attention to this issue; the lack of a clear signal from the Svelte core team has allowed divergent interpretations of svelte.config.js to arise in the ecosystem. For example the Parcel plugin expects this...

module.exports = {
  preprocess: {...},
  compiler: {...}
};

...while the Snowpack plugin expects this:

module.exports = {
  preprocess: {...},
  ...compilerOptions // note the `...`
};

These are mutually incompatible. (This is exactly the situation @vjeux warned us about in 2018!)

@dominikg and @dummdidumm had the right idea:

module.exports = {
  preprocess: {...},
  compilerOptions: {...},
  ...otherStuff
};

The importance of otherStuff (i.e. not having compiler options at the top level) is that it's future-proof — or more accurately, present-proof, since I currently need to use svelte.config.js to add a previously unanticipated option in a Snowpack project, which fails Svelte's validation because @snowpack/plugin-svelte passes it straight through to the compiler.

I'd strongly urge third-party integrations that use svelte.config.js to adopt this signature, though I don't know who to cc (other than @DeMoorJasper of the Parcel plugin), as I don't know the extent of who is currently using it. (Note to the Parcel plugin team: I would argue that compilerOptions is more explicit and future-proof than compiler, so would urge you to un-deprecate it. DeMoorJasper/parcel-plugin-svelte#87 says compiler was introduced for consistency with preprocessor, but the option is actually called preprocess. The two things arguably shouldn't be grammatically consistent anyway, since we're comparing functions with objects.)

Will leave this issue open until we've had a chance to document this stuff.

[dominikg]

Great to see this is being picked up.

couple of points for documentation/future discussion

1. Should rollup-plugin-svelte read from svelte.config.js by default? cc @benmccann
2. Should "otherStuff" be formalized in some way (eg require namespaces to avoid clashes on top level properties)?

{
  preprocess: {},
  compilerOptions: {},
  snowpack: {},
  svite:{},
  ...
}

3. Should there be a canonical location for svelte.config.js (always project root or resolve upwards in directory tree also see Glob pattern support for different Svelte files in svelte.config.js language-tools#410.)
4. Typings? svelte.config.ts option ?

[DeMoorJasper]

@Rich-Harris thanks for coming up with a somewhat standardised config signature, I've updated the Parcel 1 plugin to use this new signature DeMoorJasper/parcel-plugin-svelte#151 also created an issue in the Parcel 2 plugin to update this as well.

Left out the otherStuff for now as it will probably end up having the same problem we had now, with tools deviating from the standard config...

[dominikg]

Another candidate for addtion to "otherStuff" could be the defaultLanguages currently exported by svelte-preprocess @kaisermann @dummdidumm

[kaisermann]

I like formalizing a way to define the default languages, but as it's completely related to the preprocessing step, wouldn't it be a bit weird to have it as an adjacent property?

module.exports = {
  preprocess: [...],
  defaultLanguages: { ... },
  compilerOptions: { ... }
}

Also, should we have an easy way to get the contents of a svelte.config.js file, and should preprocessors consume it? Otherwise, it will be needed to define the default languages twice, i.e for svelte-preprocess.

const defaultLanguages = { ... }
module.exports = {
  preprocess: [sveltePreprocess({ defaults: defaultLanguages })],
  defaultLanguages,
  compilerOptions: { ... }
}

Note:
For those who don't know, nowadays the language-tools is able to read the defaultLanguages prop exported alongside the auto preprocessor of svelte-preprocess.

[dummdidumm]

I think having it inside preprocess would be nice, but would that be a breaking change or could we somehow detect "ok preprocess is not a function, then it's the new format".

Side note: I'm not so confident in default languages anymore since I don't know if all the tools can deal with it: How to tell the prettier CLI about that? How to get syntax highlighting to work with it (as far as I know the syntax JSON is static)? (Discussion about this topic should probably be done somewhere else and not this ticket)

[benmccann]

This exists now: https://kit.svelte.dev/docs#configuration

[melMass]

I'm very confused...
Should we use svelte.config.js along rollup for SvelteKit?

I'm just trying to disable source maps on production but I've looked at many outdated docs or issues, and can't wrap my head around all those config files or how they interact with each other.

[benmccann]

Please ask this type of question on Discord and not on an issue that's been closed for a long time. Rollup should not be used in anyway in SvelteKit projects

[melMass]

Please ask this type of question on Discord and not on an issue that's been closed for a long time. Rollup should not be used in anyway in SvelteKit projects

sorry 😬!
thanks I did not know about the discord, I'll join