Hi, I wanted to float an idea around configuration in the Luau tooling ecosystem.
Lute already uses lint.config.luau, which I think is a really nice direction. Using Luau itself for config is pretty cool and avoids mixing formats like TOML and JSON.
I’ve been working on a tool called Luumen, which is a CLI for working with Luau projects (scaffolding, installing dependencies, running workflows, etc.). While building it, one thing that kept coming up is how config ends up scattered across multiple files depending on the tool:
wally.tomlrokit.toml*.project.json (Rojo)lint.config.luau (Lute)
It makes it a bit harder to reason about a project as a whole.
What I’ve been experimenting with is a single project-level config file:
Where each tool can read its own section.
For example:
return {
project = {
name = "my-game",
},
lute = {
lint = {
ignores = { "**/*.snap.luau" },
},
},
tasks = {
lint = "lute lint",
},
}So instead of multiple config files, everything lives in one place, and tools just read what they care about.
Curious what you think about this direction. Would something like this fit with how you see Lute evolving, or do you think keeping tool-specific config separate is the better approach?
Hi, I wanted to float an idea around configuration in the Luau tooling ecosystem.
Lute already uses
lint.config.luau, which I think is a really nice direction. Using Luau itself for config is pretty cool and avoids mixing formats like TOML and JSON.I’ve been working on a tool called Luumen, which is a CLI for working with Luau projects (scaffolding, installing dependencies, running workflows, etc.). While building it, one thing that kept coming up is how config ends up scattered across multiple files depending on the tool:
wally.tomlrokit.toml*.project.json(Rojo)lint.config.luau(Lute)It makes it a bit harder to reason about a project as a whole.
What I’ve been experimenting with is a single project-level config file:
Where each tool can read its own section.
For example:
So instead of multiple config files, everything lives in one place, and tools just read what they care about.
Curious what you think about this direction. Would something like this fit with how you see Lute evolving, or do you think keeping tool-specific config separate is the better approach?