社区精选｜耗时一年半才出第一版，这个工具会一统前端么？

今天小编为大家带来的是社区作者 卡颂 的文章，让我们今天来聊聊Rome。

前言

---

大家好，我卡颂。

前端领域从不缺少热点，基本每过半年，就会出现新的工具。

在这样快节奏的浪潮中，有个工具却显得格格不入，他就是 Rome 。

从名字中我们就能窥探出一丝端倪，看看别的工具：

• vite （法语中 快的 的意思）

• turbopack （英语中 涡轮增压器 的意思），

再看看他 —— 寓意是 罗马不是一天建成的 。

事实也如此， Rome 团队用时一年半终于上线了第一个稳定版本 Rome v10 https://link.segmentfault.com/?enc=F6o2Np0lgjT5YSoiiweXyQ%3D%3D.00Ie92zQXB8cFnftUQv0fiz8hkLbdPQ3GkdYaVMZ6Xs8kmd%2F4AnYpgW8PQkuyQpL 。

作为前端工具链工具， Rome 和那些我们耳熟能详的工具（比如 vite 、 eslint 、 CRA ）有啥区别？未来他会一统前端么？

今天我们来聊聊这个话题。

Rome 是什么

---




Rome 的创造者是前 Babel 团队的 Sebastian McKenzie ，后文就叫他小马吧。

21 年 5 月，小马拿了 2 家风投 450w 刀的投资后成 立了 Rome Tools 公司 https://link.segmentfault.com/?enc=z0uhe%2FT1ifHqNnpKpTKK%2Bg%3D%3D.o53NXOnOz7QLjjKtZJ%2Fsbm WL10aFiP0f33OjMnh9Lc0na1qBi0iieEt6XkjpPYDMOAec8VGFN1UuMvNf7tAbcw%3D%3D

这家公司的目标是：实现一站式前端工程化解决方案，以替代现有的各种前端工具。

在小马看来，当前的前端工程化解决方案存在很多问题，比如：

问题 1:工具太多，学习成本高

对于项目中常用的一些工具，比如：

• 代码格式化工具：Prettier、dprint

• lint 工具：ESLint、StyleLint

• 测试工具：Vitest、jest

• 编译器：babel、SWC

• 打包工具：webpack、vite、rollup

要熟练使用他们并不容易，因为：

• 需要了解不同工具如何配置

• 需要考虑如何将这些工具整合到项目中

最终，项目中往往充斥着各种各样的配置文件。以至于复杂的项目中通常有个特殊的职位 —— webpack 配置工程师 。

很多脚手架工具（比如 create-react-app ）就是为了解决这个问题而生，但他们的缺陷也很明显。

他们仅仅提供了胶水层隔离了这些工具的复杂度，但如果有个性化需求时开发者还是得直面这些问题。

而对于 Rome 驱动的项目，只会有一个 rome.json 配置文件以及开箱即用的最佳实践。

问题 2:性能浪费

前端工具链的很多工具都有访问 AST 的需要，但很多时候他们是各自为战的。

比如， babel 处理代码降级时会生成 AST ， eslint 审查代码时也会生成 AST ，这就造成了性能浪费。

另一方面，前端工具用 Rust 重写已然成为趋势。

如果能将这些工具都用 Rust 实现，并尽可能减少不必要的解析过程，就能显著提高工具性能。

Rome 的基本思路就是如此。根据小马的计算， Rome 格式化代码的速度是 Prettier 的 100 倍以上：

问题 3:提示对开发者不友好

当前很多前端工具是不同团队、不同个人开发的，所以在提示信息的准确性、体验上各不相同。




Rome 在 提示信息 上下了很多功夫，比如对于如下代码：

function test(callback) {
  try {
    return callback();
  } catch (e) {
    console.log(e);
    throw e;
  }

  return 20;
}

保存为 a.js ，执行如下检查命令：

npx rome check a.js 

控制台会输出三段内容。

第一段，告诉你 return 20 永远不会执行：

后两段会告诉你为什么不会执行：

• 要不是因为 return callback();

• 要不是因为 throw e;

相比 eslint 的提示信息， Rome 的提示信息确实更友好。

未来，这样友好的提示信息会出现在 Rome 工具链的每一环，比如：

• 打包代码的信息

• lint 信息
• 测试信息

Rome 会一统前端么？

---

当前， Rome 只提供了 linter （对标 eslint ）、 formatter （对标 prettier ）两个工具，可以通过如下命令体验：

# 格式化
npx rome format 

# lint
npx rome check 

更 详尽的命令参考 官方文档 https://link.segmentfault.com/?enc=erdvm0cT28PDp2mDao8%2FAw%3D%3D.Nfu375ZnyVrC6FtCIUERr4VGb2FBV1L%2FtdfDzw2q8OzDP3WHdG271SQtpUnCWMrn

如果未来 Rome 实现了他的目标，一定是对前端开发者很有吸引力的选择。

但是，要实现这种大而全的解决方案并非一朝一夕就能完成的。

而在前端领域，新的技术、新的框架总是源源不断的出现。

同为公司级的开源产品， vercel 开发的 next.js 虽然选择了与 Rome 不同的方向（以前端框架为切入点），但两者的功能点一定有重合的一天。

从发展路径看，对于 next.js ：

• 当前： next.js 依赖 webpack 打包

• 下一步： vercel 投入到 turbopack ， next.js 依赖 turbopack 打包

• 下一步： turbopack 为了将自身速度优势发挥到极致，可能会用 Rust