tools

ixes (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.