RFC for Sapper configuration

[benmccann]

I'd like to help unblock Sapper development. It was mentioned on Discord that this was a large blocking issue. (Please let me know if there's something else I could be doing that would be more productive or welcomed).

I filed an issue to track it and solicit input and it was suggested than an RFC may be a good option for this type of issue. Sapper doesn't have its own RFC process and many of the committers to the two projects are the same, so I hope you don't mind me sending this here. I've left that issue open for the time being, but please feel free to close it.

Rendered

[antony]

My initial thoughts:

• The presence of the config file should be completely optional
• We should have svelte.config.js and sapper.config.js.
• We should validate the values in the config file using some sort of schema (I'm a fan of Joi, but there are other options)
• It should be JS
• There is a library which handles this sort of config, but I don't know a huge amount about it - I guess defer to decisions made in language-tools?
• I might not include middleware config in there. It seems like something that could be broken in server.js and become a bit mysterious.
• Having worked with and as a DevOps, I feel like ENV_VARS should trump all, even flags. I don't know what the precedence is on this.

[ajbouh]

I'm eager for this work to move forward as I am finding the current command line option approach to configuration to be stifling.

I agree with not keeping middleware config in this file, since that's actual source code and may be doing any number of custom things that have very little to do with high-level configuration.

I'd also advocate for limiting the first version of the config to just replace command line options. That would unblock a number of configuration PRs and help projects using sapper both move faster and spend their energy on making their applications that much more awesome.

RE: Environment variables, without a very specific motivating reason, I don't think you want a value that's invisible and automatically inherited (like an environment variable) to be able to override something explicit and localized.

Unfortunately the current approach to "waiting to merge" configuration PRs means people are just accumulating forks, using shell script hacks to transform outputted files, and/or abandoning Sapper in favor of alternatives that are easier to configure (but worse to use).

Most of my comments above sound negative, but I'm actually very excited about all of this and am eager to help move it forward!

[pngwn]

Closing this as it is no longer relevant. svelte/kit will have a config file and that tooling will be replacement sapper in the future.