SebastianVerified account

No interest in a rome.config.js? As someone who likes to build opinionated tools on top of other tools, being able to have a dynamic configuration is much more enabling. If not, I'm on board with rome.toml

You can always generate TOML files yourself and pass them in. Dynamic configuration is a mess. Config invalidation becomes a mess. What are the dependencies of the config? When do I need to rerun it? Do people want TS support? Increases surface area drastically.

For a tool like Rome, knowing all the possible config variants is extremely useful.

I understand that it's a challenge, but personally I've found it to be a real pain to build an opinionated tool with little-to-no config (similar to react-scripts) on top of tool that doesn't support dynamic configuration.

If I generate the toml file, then I as the user of Rome would have to worry about cache invalidation/config regeneration. I suppose that's the trade-off that's being made. It's understandable that you'd prefer to keep it simpler for the more common case

What sort of configuration would you want to generate?

For babel, kcd-scripts adds the react preset if the host project's package.json includes a dependency on react. Does similar for eslint. For jest, it adds setupFilesAfterEnv if the host project has a file under tests/setup-env.js Stuff like that.