本篇主以官方的部落格新聞為主附加一點小小的幹話，希望您也能從中得到一點想法。
故事從這裡說起，第一次看到 Rome 時，當時官網的圖是長這樣。
OS：哇！帥帥的，原來又是一套建置工具，好吧！等它大紅大紫的那天在說吧！畢竟年紀大了沒什麼動機和好處實在是懶的追了，如果只是統一成 Monolithic 的架構那好像也還好（干貨呢？），雖然當時掛載 Facebook 底下，雖然在設定專案相關工具的時候的確考量相關套件是不是官方支援的比重吃蠻重的，當時的結論就是好像…不用…立馬跟上吧。這是我當時的想法…
自此之後，對這個東東便有點興趣缺缺，直到昨天我偶然點開了這篇 — Introducing Rome by Sebastian McKenzie
奇怪！Logo 變醜了 XD 原本還挺帥的說。不讀沒事…一讀… 原來是一個坑啊…
下面段落是官方 8/8 部落格原文的翻譯或者您可以直接看上面連結，然後下個小結：
（譯）Rome 介紹
我們很高興發佈 Rome 通用於 JavaScript 和 TypeScript 的 Linter 第一版 beta。這是整個工具套件的第一步。Rome 不只是 Linter 而是給 JavaScript，TypeScript，HTML， JSON，Markdown，CSS 使用的工具包含編譯器，打包（Bundle）工具，測試執行(Test Runner)等等。我們的目標是統一前端開發的工具鏈。
Rome 是一個單一完整的工具有別於傳統前端生態圈中套件分散各自分責的形式，我們稱它為 — 工具鏈。它不是既有工具的集合，而是完全重新開發的單一套件。
Rome 的目標就是取代 Babel，ESLint，webpack，Prettier，Jest 還有其他工具。
我們已經完成大部分功能核心的部分，包含編譯，封裝打包，測試等全部都使用相同的核心抽象層和內部函式庫。Rome 甚至實現了 self-hosted 意味著我們就是使用 Rome 來建置和開發 Rome 本身。一旦 Linter 可以穩定使用，我們將繼續準備其他未發佈的功能。
對我們來說，分析和發現程式碼中的問題(Linting)是一個低風險的功能，協助我們發展和檢查共用的功能例如編輯器整合，設定，平行化，快取，解析，相依性分析。因為它不是開發最關鍵的部分，因此相對安全可以直接使用。
$ rome check雖然這只是 beta 但我們已經支援 100 條檢查規則，包含在使用 TypeScript 和 React 時常見的規則。詳情請參考完整規則列表。
自開源以來，今年初，我們就已經收到超過 70 位協作者 600 個 PR 。也因此建立了團隊，正式的協作流程，程式碼規範等。這樣可以確保項目決策，審核和指導的透明度。
現在您可以閱讀文件來了解 Rome 例如入門等，如果您想要參與開發，可以參考協作指南。如果您對於專案的歷史和基本原理有興趣可以繼續閱讀下面的內容。
專案歷史
在 2014 年我建立了 6to5 現在則叫 Babel，一個 JavaScript 的編譯器用來編譯新的 ES6 程式碼成 ES5， 然後就可以在任何瀏覽器上執行。當時我沒有要解決任何特定問題就只是嘗試使用一些既有的函式庫去建置，實驗這個想法，甚至是在過程中學習一些新的觀念。隨著時間推移，專案爆紅，專案處理的範圍和目標也爆炸性成長。
我們把專案名稱從 6to5 改成 Babel，更適合這個專案的新角色 — 作為一 JavaScript 轉譯的通用平台。意思是加入一個新的擴展套件機制和承擔起支援未來 JavaScript 新標準和提議的功能。
我們還計劃通過使用共享的函式庫來擴展 Babel，作為其他 JavaScript 工具的基底。您可以閱讀 Jamie Kyle 發佈的 6.0.0 釋出 ：
我們認為我們可以做的更多。Babel 應該支援最小優化，格式整理，語法高亮，IntelliSense 程式碼補齊，型別檢查，codemode 重構協助工具，並協助其他使用相同基礎的工具提供更好的功能。 - Jamie Kyle2016，我離開的這個專案，那些計畫尚未實現。又過了一陣子，我發現 Babel 仍然無法實現其願景。其中擴展套件的作法已經公開了所有內部資訊 — 即需要維護極其大量的 API 介面並限制了調整。
如果要使 Babel 成為其他工具可靠的基礎肯定需要全盤的調整修改。該架構與我和 2014 年學習解析器、AST、編譯器時做出的選擇有關。
不可能提供向後兼容性，對該項目的任何重大更改都將帶來極大的影響。
就像忒修斯之船說的 — 如果所有元件都變了，那它還是原來的東西嗎？與其徹底修改已經被廣泛使用的東西，發佈全新的東西產生的混亂與摩擦要少得多。從那之後我就離開了該專案，所以任何重大調整變得更難以實現，而且還需要完整的、對的方向。
雖然我沒參與 Babel 了，但我還是在開發工具的生態圈裡，最後我跑去開發了其他類似 Yarn 的工具並參與了Prepack 和 Flipper 。這些工作不斷在影響我在這個點子上的發想，最終變成 Rome 以及淬鍊出過去開發經驗的哲學 — 專注於提供有效的錯誤訊息，精簡的介面，最小化的設定。
Babel 背後的原始想法始終存在。如果工具能夠多做一件事，那可能會產生什麼功能或質變呢？這種想法在 JavaScript 生態圈似乎比較少見，其中最小責任化抽象和關注點分離似乎是規範一般。獨立分散的工具從沒有像多數懷疑完整整合工具的人所說的那樣，讓使用者自己選擇以及更有效率。
程式語言工具的維護者花了很多時間做一樣的事。處理原始碼，無論是像 Babel 一樣的編譯器， ESLint 這樣的分析工具，webpack 這類的封裝打包工具。從根本上來說技術是重疊的。
JavaScript 生態圈的 Linter 和編譯器幾乎是一樣的。它們都要分析程式碼然後產生編譯結果和錯誤訊息。雖然結果有些差異。但以 Linter 來說，結果是格式化的程式碼和套用修正結果。如果編譯器的功能越強，理論上 Linter 就可以越強。這些共性幾乎可以擴展涉及語言處理的所有功能。我們就可以使用共用的基礎建置更強大的工具。
基本上大部分的時間我都在維護私人的專案和實驗一些想法，這些程式碼變成 Rome 是從 2017 年開始，當時我在業餘時間為 Facebook 工作。我持續嘗試實驗這個想法然後建構不同的部分，直到 2019 當我在 Facebook 全職工作時才有機會研究和使用它。
後來我離開了 Facebook ，專案在 2020 二月開源，後續將以一個獨立社群的方式繼續這個專案。
精神上，Rome 是 Babel 的後繼者。從過去吸取的經驗，與其揭露完整大量的 API 給其他工具使用，不如將它們全部都放在統一的地方，統一內建支援。很高興能嘗試 JavaScript 和網絡生態系統以前從未見過的新事物。
小結
很顯然 Rome 已經立志要成為海賊王了。讀完關於專案的歷史之後，不得不說統一這個點有些說服我，加上過去自己升級專案工具和 Babel 還有自己開發的 webpack plugin 升級時就有一些覺得週邊的東西好多好散亂。我自己是樂見其成的。
講那麼多，現階段其實也沒辦法直接幫上實戰太多，但會開始把它放入追蹤名單，畢竟現今的霸權已經鞏固好一陣子了。究竟 Rome 能否成為海賊王就讓我們看下去。
