trunk-rs/trunk

Re-thinking configuration

Open

#780 opened on Apr 19, 2024

 (18 comments) (0 reactions) (0 assignees)Rust (315 forks)auto 404
help wanted

Repository metrics

Stars
 (4,347 stars)
PR merge metrics
 (PR metrics pending)

Description

Right now there's a layer of configurations (order of priority, former will override latter):

  • CLI (clap)
  • Environment variables (mapped to serde with envy)
  • Trunk.toml config (serde)

The result is then passed on internally to structs for processing.

There are some areas of improvement:

  1. It doesn't always make sense to have the same behavior between CLI and config.
  2. CLI options sometimes influence how the configuration will be read
  3. environment variables get pushed into serde model, but actually are closer to the CLI model
  4. there are some inconsistencies (proxies, boolean flags not overriding false)

There are also some pending feature requests which seem to have an impact on the configuration:

  1. Profiles: It would be great if trunk would support build profiles. However, I would not really make sense to map those profiles to the CLI/env-vars. Only the selection should go there. However the profile selection should not be part of the serde configuration (also see: https://github.com/trunk-rs/trunk/issues/605).
  2. There was a discussion about adding the configuration to the Cargo.toml (personally I am not a fan of this, bet maybe we can have it both ways)
  3. Some parts of the build might want to have additional configuration (like minification level for CSS)
  4. There's the idea of plugins (has not manifested yet) But how could a plugin have its own configuration?

Bonus points:

  1. Allow other formats, beside TOML (I am looking at YAML). I would not force YAML on anyone, but with YAML it would be possible to leverage JSON schemas to enable IDE editor support.

Contributor guide