-
Notifications
You must be signed in to change notification settings - Fork 664
☂️ One config format, in one place #1596
Comments
I also should probably explicitly call out that I think it would be better if the See |
I think that JSONC is a good choice, and I don't think there are compelling reasons to deviate from a syntax that the community is already familiar with. I like TOML for simple config, but personally, I think it's easier to quickly understand nested config in a json-like format (especially when you can easily fold/expand sections in your editor). And ultimately, I hope our cli is powerful enough that most tutorials will be able to say "run these |
I actually feel the opposite way. TOML avoids the problems of nesting because using tables you're always not far from context: [lint]
# ...many lines of code...
# ...many lines of code...
# ...many lines of code...
# ...many lines of code...
# ...many lines of code...
[lint.rules]
# ...many lines of code...
# ...many lines of code...
# ...many lines of code...
# ...many lines of code...
# ...many lines of code...
[lint.rules.a11y]
noAccessKey = true
noAriaUnsupportedElements = false I don't have to scroll and match indentation/braces to see where I am. Even with braces-folding you still end up with a lots of content to scroll through. You can also text search in your editor "lint.rules.a1" and jump directly to the right section.
I think regardless of what our documentation/cli/etc does, users are going to communicate with one another via config. Even though git has a similar CLI for editing config as Rome, there are still thousands of stack overflow answers that paste config into them, and the average Rome config file will probably larger than the average git config file. |
How does Rome handle environment specific configs? Like dev/prod/local/etc? |
I think @milesj has a valid point, the CLI at least should include an option to override the path (or at least the filename) of your config. This would make it much easier (also for CI) to match for dev/prod/local/etc. Otherwise, CI needs to create a file out of each context. |
I don't want to go into too much detail in this issue, but at a high level, I don't think that Rome needs/should have environment-specific configuration for a few reasons:
Rome can and should be very flexible, but not at the expense of pushing every decision onto every user. And we'd like to preserve the ability for us to push out situationally-aware improvements to everyone without asking them to opt-in all the time. |
I'd go for TOML. Haven't used it much before but just from these few examples I already understand it. So I don't think that learning it would be a problem. TOML being somewhat capable of being read and reformatted when incorrect is also a plus, ref: https://twitter.com/buildsghost/status/1408492371357028353. Having worked with JSON and JS config files, finding the correct context is a huge hassle. Same for formatting i.e. missing bracket/colon/comma/... I'd prefer some repetition (TOML keys) over indentation hell. For comments you'd have to manually set the file language as most editors will complain. I think having a single format would be better for everyone, removing the need to know all of them when providing/needing support.
We could definitely include an option like @jamiebuilds would we only use |
Yeah, I mean... if Rome is successful, then we'll be eliminating the need for a lot of config files. ExampleI have a project right now that looks like this:
If you were to only use Rome tools, that could look like this:
Maybe in the future even:
But in the meantime a couple things:
|
Ok, understood. But actually I would still give the user the ability to define a custom file. There are multiple use cases where there are other build tools (whose use cases Rome cannot handle), and with it configuration files. When it comes to project structure, I would always prefer having build tool configuration in one folder. So she Config file decision should be available for me. But not mandatory to be set. |
I am happy with either. I personally like TOML syntax and first time I started looking into it, I got the hang of it quite quickly. It has rules, it supports comments out of the box, it's really expressive and "flat" (no nested things). Comments inside a JSON seems, to me, unnatural. Regarding the position of the file, having it inside the root folder is a good idea. @iduuck The Rome config file accepts a
The config files would look like this # inside rome.toml
root = true
name = "project"
extends = [ "./rome-config/config.toml" ] # inside config.toml
[lint]
enabled = false
[format]
enabled = true |
I'd say we could move the config file in the root folder, away from After that we could use some telemetry to understand which projects prefer to use |
Spoke more about this as a team:
|
Have you considered using plain |
We did and we want to stay away from that approach for various reasons. |
Not sure if this is out-of-date but you're saying that Rome allows |
@scarsam Since the rewrite to Rust, we haven't been able to port ALL the old features we had. This is one of them, we plan to add it again soon. Unfortunately, I can't give you a timeline. Once there, the documentation will be updated! |
I want to address this before we ship the 0.1 release.
One of my bigger regrets on Babel is not sticking to a single universal config format that was always in one place in the file system. It largely grew out of the many different integrations with Gulp, Grunt, Webpack, etc. where people configured Babel with its library API. But today you have:
I think this is really bad for the community:
I would suggest that we have a single config file
rome.???
and it always appear at the "root" of the project (whether that is the git root or some other folder), or some "workspace"-like folders that belongs to a shared root.I think the best two choices for this config file are either:
rome.toml
rome.json
(parsed as JSONC -- the same formattsconfig.json
uses)I think it would be a big mistake to use a dynamic language like javascript for this format as it complicates caching, removes the point about being copy-pasteable, and makes it impossible to have CLI tools that automate it.
Some quick pros and cons with either syntax:
JSONC:
TOML:
[table.with.context]
syntax makes copy-and-paste very easy.[lint]
[lint.rules]
[lint.rules.js]
Overall my personal preference is TOML, but I would be happy with either.
The text was updated successfully, but these errors were encountered: