5 ms·

Eslint can get VERY slow on large apps. Rome seems to be the perfect answer to that, but I can't seem to find a way to port/import Eslint rules into Rome.

vlovich123 3y ago
That’s because it only supports a very small subset of lint rules. As best I can tell, the rules are very opinionated often in weird ways and not particularly as complete as ESLint.
- Raed667 3y ago
  Thanks for the clarification. So it is basically only suitable for greenfield projects?
  - progx 3y ago
    It works as it should, as a user you have to accept that rome works in a specific way. If you can do that and live with that, rome is a excellent tool. It took me some weeks to accept the "rome way" and now i am more than happy with that and did not waste time with endless configurations of eslint/prettier.
    - Raed667 3y ago
      When you have a large project with +500k lines of code, two dozen contributors, tens of eslint rules, it is very hard to "just" do it the rome way. A migration path is required, otherwise you'll introduce a tool, have a PR that reformats everything and it will be a huge mess.
      - conaclos 3y ago
        Rome is less opinionated than it used to be. However, I admit it is still more opinionated than ESLint. It is part of its ADN. However, Rome is also trying to provide a smooth experience. And we are open to relax some rules if it makes sense. If you have some time, we would like to get to know the rough edges of Rome.
        Raed667 3y ago
        Thanks for both comments and the clarification! I'll give it an honest shot tomorrow and update you on the pain points.
        conaclos 3y ago
        Hey! Have you had time to test?
      - campers 3y ago
        After you commit that big PR add the commit hash to the .git-blame-ignore-revs file. Then it won't affect the git blame attributions. https://docs.github.com/en/repositories/working-with-files/using-files/viewing-a-file#ignore-commits-in-the-blame-view https://docs.github.com/en/repositories/working-with-files/u...
conaclos 3y ago
For now, Rome implements most of the ESLint recommended rules (including TypeScript ESLint) and some additional rules that are enabled by default. In the future, you can expect a recommended preset that is a superset of the ESLint recommended preset. So if you're not heavily customising ESLint, you should be able to use Rome. Otherwise, most of the rules are not fine-tunable in the way that ESLint is. Rome tries to provide the experience that Prettier provided in the formatting landscape: good defaults for a near-zero configuration experience. It tries to adopt the conventions of the JS/TS community. Still, some configuration is provided when the community is divided on some opinions (e.g. space vs. tab indentation, semicolons or as-needed semicolons, ...). There is an open issue [1] for listing equivalent rules between ESLint and Rome. Expect more documentation in the future, and maybe a migration tool. If I had been one of the founders of Rome, I could have pushed for more compatibility with ESLint. In particular, using the same naming conventions and thus the same names for most rules, and recognising ESLint ignore comments. [1] https://github.com/rome/tools/issues/3892 https://github.com/rome/tools/issues/3892

vlovich123 3y ago

That’s because it only supports a very small subset of lint rules. As best I can tell, the rules are very opinionated often in weird ways and not particularly as complete as ESLint.

Raed667 3y ago
Thanks for the clarification. So it is basically only suitable for greenfield projects?
- progx 3y ago
  It works as it should, as a user you have to accept that rome works in a specific way. If you can do that and live with that, rome is a excellent tool. It took me some weeks to accept the "rome way" and now i am more than happy with that and did not waste time with endless configurations of eslint/prettier.
  - Raed667 3y ago
    When you have a large project with +500k lines of code, two dozen contributors, tens of eslint rules, it is very hard to "just" do it the rome way. A migration path is required, otherwise you'll introduce a tool, have a PR that reformats everything and it will be a huge mess.
    - conaclos 3y ago
      Rome is less opinionated than it used to be. However, I admit it is still more opinionated than ESLint. It is part of its ADN. However, Rome is also trying to provide a smooth experience. And we are open to relax some rules if it makes sense. If you have some time, we would like to get to know the rough edges of Rome.
      - Raed667 3y ago
        Thanks for both comments and the clarification! I'll give it an honest shot tomorrow and update you on the pain points.
        conaclos 3y ago
        Hey! Have you had time to test?
    - campers 3y ago
      After you commit that big PR add the commit hash to the .git-blame-ignore-revs file. Then it won't affect the git blame attributions. https://docs.github.com/en/repositories/working-with-files/using-files/viewing-a-file#ignore-commits-in-the-blame-view https://docs.github.com/en/repositories/working-with-files/u...

conaclos 3y ago

For now, Rome implements most of the ESLint recommended rules (including TypeScript ESLint) and some additional rules that are enabled by default. In the future, you can expect a recommended preset that is a superset of the ESLint recommended preset. So if you're not heavily customising ESLint, you should be able to use Rome. Otherwise, most of the rules are not fine-tunable in the way that ESLint is. Rome tries to provide the experience that Prettier provided in the formatting landscape: good defaults for a near-zero configuration experience. It tries to adopt the conventions of the JS/TS community. Still, some configuration is provided when the community is divided on some opinions (e.g. space vs. tab indentation, semicolons or as-needed semicolons, ...). There is an open issue [1] for listing equivalent rules between ESLint and Rome. Expect more documentation in the future, and maybe a migration tool. If I had been one of the founders of Rome, I could have pushed for more compatibility with ESLint. In particular, using the same naming conventions and thus the same names for most rules, and recognising ESLint ignore comments. [1] https://github.com/rome/tools/issues/3892 https://github.com/rome/tools/issues/3892