Synchronise with svelte.config.js

[Rich-Harris]

Two parts to this:

• the plugin should accept a compilerOptions property, instead of just throwing top-level options at the compiler (we can detect unexpected top-level properties and warn accordingly, so while this will be a breaking change — which is fine, since we're about to release a major — it needn't be a confusing one)
• it should load a svelte.config.js if one exists. (do we allow config to come from other places, like svelte.config.json? my gut says no, keep it simple)

[lukeed]

Gut also says "no" to varying config files. That's always a headache – for user and toolmaker.

1. Have we settled on compilerOptions as a name?
2. Uneasy about auto-loading svelte.config.js – dealing with cwd and what "root" means is a PITA & doesn't make a ton of sense from a Rollup plugin perspective. The only things I can think of that do this are TS plugins, but they don't actually do it – it's typescript itself that autoloads.

As part of (2), I think I would prefer this (as both user & toolmaker):

svelte({
  compilerOptions: require('../path/to/svelte.config.js')
})

[benmccann]

We already need to deal with cwd / root:

rollup-plugin-svelte/index.js

Line 164 in a765821

const filename = path.relative(process.cwd(), id);

[lukeed]

I don't find that one as problematic because id is already a resolved, absolute path. That's giving the Svelte compiler an identifier to work with

[Rich-Harris]

1. Have we settled on compilerOptions as a name?

Yep, that's what was discussed in Discord and communicated here, and plugins are in the process of switching to support that if they don't already

I don't have a strong feeling one way or the other about auto-loading (and the two things can certainly happen independently), but worth noting that it wouldn't just be a case of this...

svelte(require('../path/to/svelte.config.js'))

...because svelte.config.js could contain keys that this plugin shouldn't accept. So at the very least it would need to be this:

const { preprocess, compilerOptions } = require('../path/to/svelte.config.js');

// later...
svelte({
  preprocess,
  compilerOptions,
  ...anyOtherPluginOptions
})

The cwd thing is only really an issue if you're invoking Rollup programmatically, because Rollup will itself fail if you run it from somewhere other than the project root:

cd src
npx rollup -c

[!] Error: Could not resolve entry module (rollup.config.js).

cd src
npx rollup -c ../rollup.config.js

[!] Error: Could not resolve entry module (src/index.js).

That may be enough of a reason not to bother with it — as I say, I don't have a strong opinion

[lukeed]

I typo'd on my snippet, but ya, agreed there.

I think we can punt on the autoload decision & let that be a 7.1.0, for example, once we/any of us feel more strongly about it.

For now the question we have to answer now is whether or not compilerOptions is the only way for this plugin to accept svelte/compiler options. In interest of uniformity I saw yes to that being part of 7.0's breaking changes

[Rich-Harris]

Sounds good to me

[dummdidumm]

A question about importing the svelte.config.js: right now this config has to be written in commonjs style because it's loaded by the language server through a dynamic require. AFAIK you can write rollup configs using esm style. Is that a problem?

[lukeed]

ESM files can still require CommonJS files. It just doesn't work the other way around