We could alternatively support both. I can write a parser for either pretty easily. I really despise both formats, I think they're truly awful, but others seem to like them so I'm willing to concede.
They offer the same advantages we have with RJSON, but are actual community standards with great portability and interopability. Supporting both would also allow us to better integrate into the ecosystem of other languages.
ie. In a ruby project all config would be written in YAML, so having your Rome config also in YAML would be much more comfortable. TOML in Rust etc.
Personally, I don't like YAML. It's very sensible to tab/spaces... let's say I haven't had a pleasant experience so far.
But objectively, it's better to support a standard format (or more known/used) because it integrates better with the current ecosystem (IDEs, existing libs, etc.)
I'm definitely in favor of switching to support one or more community standards.
We're trying to minimize the amount of configuration that people need to do anyway, so I don't think the ergonomic benefits of a custom format outweigh the lack of interoperability.
At the moment we internally use RJSON for testing our lint rules. If we decided to support YAML/TOML, what would happen to these files?
I can't see them ported into a YAML file. Would we port them into a JSON file?
YAML wouldn't be too bad since you can do multi-line strings like:
example: >\n
路路Several lines of text,\n
路路with some "quotes" of various 'types',\n
路路and also a blank line:\n
路路\n
路路plus another line at the end.\n
We could pick whatever config format we would want to use internally.
I suggested keeping the RJSON format as its very intuitive and I have already written serializer and deserializer for a similar format named EKON. TOML is good but not very intuitive.
Here's the discussion:
https://github.com/rome/tools/discussions/1410#discussion-3284874
Most helpful comment
I'm definitely in favor of switching to support one or more community standards.
We're trying to minimize the amount of configuration that people need to do anyway, so I don't think the ergonomic benefits of a custom format outweigh the lack of interoperability.