Rome: A Linter for JavaScript and TypeScript

"All roads lead to Rome" is the reference

Thanks! Yeah, it is, at least for a while since it will take a very long time to reach expected maturity. You can adopt as many or as little pieces as you want. The idea is that once you adopt one of the "tools", you can use the others and reuse the exact same configuration, and ideally you shouldn't even need to do anything else.

ie. For linting we also do dependency verification. So you might need to configure Rome if you put your dependencies on some weird non-standard place. Once we open bundling up, we'll already know how to resolve everything.

Each part should stand on it's own. It's not as if the linter we've released is worse, and the only selling point is that it's going to be part of a larger suite. It legitimately has features and separates itself from the alternatives. eg. extreme focus on useful error messages, powerful autofixes (that operate on an AST rather than insert strings like ESLint), proper caching for even better performance (ESLint doesn't offer a good solution here) etc.

Many are making the mistake in thinking that building Rome is just as time consuming and resource intensive as rewriting each of the tools it's meant to replace separately, it's not. Once we've validated the linter we've also validated the compiler (it's the same thing), our ability to watch files, analyze dependencies, integrate with your editor etc. Sharing so much fundamentally decreases the actual complexity of everything, not increases.

I think it's also important to note that I personally have written an extremely small amount of the implemented lint rules. Our API is just easier to use, and we've focused on setting up the tooling necessary to make writing them easy (although internally in our repo).

Check out https://github.com/romejs/rome/issues/341, https://github.com/romefrontend/rome/issues/20, and https://github.com/romefrontend/rome/issues/159, if you're interested in seeing how the progress was actually made in the implementation of those rules. The work was spread out over a really long time, and if given complete focus and proper coordination (I was not good at this and kind of let it be organized ad-hoc, which is actually how we got some amazing contributors), then it could have been completed in a fraction of the time.

There's been some overfocus on particular things like minimal configuration and the lack of extensibility but those are not hard requirements and will evolve over time, particularly as we get feedback and people demonstrate the requirements and restrictions they're under. The project understandably involves a lot of hubris, but I do believe that Rome isn't only valuable in aggregate and will have significant advantages even if you only decide to use one piece.

It's both.

I find this interesting. One of the things I like about languages like Go, Dart, and Rust is their robust tooling.

Depends on what it is I think. We discussed the idea of "expansion packs" which would enable certain funtionality as a sort of "limited config" hack. https://github.com/romefrontend/rome/issues/173

I specifically call out not allowing smaller communities to grow that don't have the advantage of their community size being forcing functions for support. It's the most compelling reason to me to even have any sort of plugin or custom rules system in the first place.

Although we didn't go through with that idea because they can just be enabled by default since the patterns they're linting for are unambiguous, I guess that applies to any additional ones, although so far the way we've approved these sort of these has been adhoc. There's a strong desire though to formalize some "approval process" for lint rules and more typical project decisions.