It's not that crazy when you look at the dependencies themselves: - 17 of them are just to connect the core dependencies with each other. Having one single too

It's not that crazy when you look at the dependencies themselves: - 17 of them are just to connect the core dependencies with each other. Having one single tool means you can drop those. - 12 are "plugins" for different parsers/linters. I believe third-party parsers/linters is something that will keep existing in Rome. - 11 are plugins, loaders and other tools that provide additional functionality to the core tools, such as loading raw files, loading raw HTML, handling case sensitive paths, inject hot-loading code. They range from trivial to complex (webpack-dev-server). We don't know how much of that functionality Rome will have built-in, so those might not be going away. - 1 is a wrapper around the core tools, 1 contains polyfill and 7 are "util" packages that do just one thing each (taking a cursory look, most of those are already implemented in Rome). - 5 are the core tools are Rome intend to replace: Webpack, Babel, ESlint, Terser and Jest. The most complex of the four was built by the Rome author himself. - There's also Typescript and PostCSS but those are third-party dependencies, and AFAIK Rome doesn't intend to replace those). When you take into account that the first four are tools built around parsers it makes A LOT of sense to put them all into a single tool, and there's a lot of overlapping functionality. The hardest part is not really replacing the core four tools, but rather replacing the whole ecosystem that exists around ESLint, Webpack and Babel. But if the AST format is the same, there's a chance that a compatibility layer would be enough to even use ESLint/Babel plugins in Rome! Sure you might lose a bit of edge cases and features (Webpack has a lot of things), but it will be entirely reasonable to start a new project with Rome when it's ready without losing much. Replacing those tools in an existing project is probably very hard, though: there's a bunch of Webpack non-standard features that cause vendor lock-in, but as someone who migrated large Webpack projects to use Rollup or Parcel, it's not as hard as it seems IME. But yeah it's hard.