Original article: https://aralroca.com/blog/do-all-roads-lead-to-rome
Perhaps you wonder if we can handle Webpack, Babel, Prettier, Jest, etc with this Rome CLI? The answer is NO... Rome implemented all these toolchain from scratch, without any dependency, using the same configuration file for everything.
The person behind this project is Sebastian McKenzie, the same author of Babel and Yarn, who has also worked on projects such as Prepack and React Native.
Rome is still in beta, and right now the current areas fully implemented are linting and formatting. The other areas are still in development.
Current tools as webpack, TS, Babel, or ESlint, among others, run their own parser to generate an Abstract Syntax Tree (AST). After this, they manipulate and process their own AST.
When all these tasks become the only tool (Rome), we'll be able to reuse the AST for each task, parsing the files only once. Also, some processes will be simplified, for example: watching files, dependency verification, or integration with your editor.
- Maintainers/contributors: simplifies all unnecessary duplications.
- Developers: a faster development experience with less consumption of resources.
Right now we need to configure too many tools for a simple feature, for example, to work with absolute imports you need to configure ESLint, TS, and also webpack!
Instead, using the same tool (Rome) removes the duplicated configurations, so we'll only have one config file.
In addition, some tools configurations are currently depending on others, for example, Prettier has to be integrated with ESLint to avoid conflicting formatting. Often these tools integrations require adding a whole bunch of plugins to make them work together but, with Rome, we don't have the need to use any plugin since all the tools are perfectly integrated.
- Maintainers/contributors: Tools like Babel had exposed all their internals to allow the creation of plugins, making it much more difficult to maintain and evolve.
- Developers: For a feature, you only need to touch one configuration, simplifying the development without the need of plugins. It also makes it much easier to reuse settings between projects.
devDependencies for all the tools and their plugins: Jest, Babel, Prettier, webpack. Besides, each of them have their own dependencies.
With Rome, many of these
devDependencies disappear, moreover Rome has zero dependencies.
So we have:
- Stronger security: The chance to have a vulnerability decreases because we drastically reduce all dependencies.
- Better maintenance and evolution of your project: Before, updating a new release of some tool could have broken the integration with another one. Now all is under one well-integrated big tool.
- Better maintenance and evolution of Rome: Rome has no dependencies, this means it has a lot of flexibility and a great innovator potential. For example, if they wanted to migrate to another language using wasm, they could do it.
Faster installation: You won't have to wait so long after doing
npm install. Less things to install.
As we've seen in the previous sections, Rome makes it much easier to start a project.
In order to take the first steps in Rome, you can install it via
npm, and then run
npx rome init /
yarn rome init to create the default
Finally, you can use every command of the CLI using
rome [command], as
rome check for linting and formatting a set of files,
rome format to format a single file,
rome start to start a daemon, etc. You can see all the available commands by running
We started the article questioning about if Rome is going to replace all current toolchain. It's a question that will be answered over time, depending on the adoption of Rome within the community and the evolution of Rome and the current tools.
From my point of view, I think that in the short term the answer is "no". Although it replaces the functionality of those tools, that doesn't obsolete them. There are still a lot of projects that depend on them. However, in the long term I think the answer would be "yes". It may not be Rome, maybe another similar approach like Deno adopting a similar philosophy of having everything integrated.
You may be wondering if one of the pieces doesn't fit 100% your needs and you still want to use your old tool. For example, you could prefer to continue using webpack as a compiler. The good thing about Rome is that if you only want to use one piece, you can. Thus, you can also use all of Rome's pieces except the compiler, to continue using webpack or another one.