摘要：原文今天我發布一個格式化工具它的靈感來源于它對于和的語言特性有著高級的支持通過將解析為并且基于美化和打印會丟掉幾乎全部的原始的代碼風格從而保證代碼風格的一致性跟不一樣的在于它沒有大量的和需要管理不過同時有一點也很重要一切都是確定好的我很高

原文 http://jlongster.com/A-Pretti...

今天我發布 Prettier, 一個 JavaScript 格式化工具. 它的靈感來源于 refmt, 它對于 ES2017, JSX 和 Flow 的語言特性有著高級的支持. 通過將 JavaScript 解析為 AST 并且基于 AST 美化和打印, Prettier 會丟掉幾乎全部的原始的代碼風格, 從而保證 JavaScript 代碼風格的一致性. 跟 ESLint 不一樣的在于它沒有大量的 options 和 rules 需要管理. 不過同時有一點也很重要, 一切都是確定好的.
我很高興的隨著離開 Mozilla 之后我有時間做自己的開源工作了, 這是我 2017 年的開始.

下面是一個在線運行的 Demo. 注意語法是支持 JSX 和 Flow 的. 你可以在下面的編輯器里輸入任何代碼, 代碼會被自動格式化.
行長的最大值是 60. 兩個編輯器當中上面一個是原始輸入, 下面是格式化之后的版本.

//                                           60 chars -->   |
function makeComponent() : int {
  return {
    longCall() {
      complicatedFunction(importantArgument(), secondaryArgument())
      weirdStyle({ prop: 1 },
        1, 2, 3);
    },
    render() {
      const user = {
        name: "James"
      };
    return 

        hello ${name}! JSX is supported
      
;
    }
  };
}

//                                           60 chars -->   |
function makeComponent(): int {
  return {
    longCall() {
      complicatedFunction(
        importantArgument(),
        secondaryArgument()
      );
      weirdStyle({ prop: 1 }, 1, 2, 3);
    },
    render() {
      const user = { name: "James" };
      return (
        

           hello ${name}! JSX is supported
        
      );
    }
  };
}

(上面的 Demo 運行在 Prettier 0.0.8)

很多人知道我在寫 React 代碼的時候通常不會寫 JSX. 一個月之前我想試試了, 我猜意識到擋在我前面的是 Emacs 對 JSX 支持不足的問題. Emacs 對代碼縮進本來有不錯的支持. 我從來不需要手動多縮進什么東西. 但是對于 JSX 卻不起作用, 我看了下其他的編輯器, 也看到了類似地問題(其他的編輯器在強制糾正縮進規則這方面基本上做的更差).

大概在同時我用了一段時間 Reason, Reason 提供了 refmt 工具用來自動格式化代碼. 我就被迷住了. refmt 屏蔽了寫代碼當中很多讓人分心的因素. 你可以按自己的習慣隨便寫, 然后格式化掉. 我意識到這不僅可以解決 JSX 的問題, 它也可以對任何編輯器提供強制整個團隊代碼樣式的一致性的工具.

如果說計算機擅長做某個事情的話, 計算機會擅長解析代碼和分析代碼. 所以我準備把這個事情做出來, 這樣就有了 Prettier. 我并不打算從底層開始寫, 所以 Prettier 是從 fork recast 的 printer 開始的, 內部用 Wadler 在 "A prettier printer" 的算法進行了重寫.

為什么選這套算法? 首先要看下為什么已有的樣式格式化工具并沒有實際的效驗.

已有的樣式格式化工具缺失了一個極為重要的部分: 最大的行長. 當然, 你是可以用讓 ESLint 在行長過大時警告的(ESLint 不會知道怎樣修復它). 最大行長是格式化工具決定性的一個部分, 特別是用在布局和折疊代碼.

比如看下面的代碼:

foo(arg1, arg2, arg3);

看上去格式化的方式是對的. 然而我們都會遇到這樣的情況:

foo(reallyLongArg(), omgSoManyParameters(), IShouldRefactorThis(), isThereSeriouslyAnotherOne());

我之前的格式突然就不正常了, 因為太長了. 你多半會這樣來處理:

foo(
  reallyLongArg(),
  omgSoManyParameters(),
  IShouldRefactorThis(),
  isThereSeriouslyAnotherOne()
);

這個例子清楚地展出了最大行長對于我們想要的代碼的樣式有著直接的影響. 目前的樣式工具無視了這一點, 也就意味著在這個麻煩的場景當中它們毫無幫助. 團隊里的每個人會按照他們自己不一樣的規則調整代碼的樣式, 因而我們也就失去了我們想要的一致性.

Wadler 算法的論文描述了基于約束的代碼的局部系統. 它會"測算"代碼的長度, 如果超過了最大行長, 就會折行.

即便我們不顧行長, 在各種 linter 工具里也有很多辦法偷懶. 我所知道的最嚴格的 linter 也會讓這樣代碼的代碼通過:

foo({ num: 3 },
  1, 2)

foo(
  { num: 3 },
  1, 2)

foo(
  { num: 3 },
  1,
  2
)

Prettier 通過解析代碼和基于 AST 重新生成滿足自己的規則的代碼, 計算考慮了最大行長, 必要時進行代碼的折行, 最終屏蔽了各種過于自由的樣式.

為了讓 Prettier 變得實用我做了大量的工作. 目前輸出的代碼已經不錯了, 我估計后面還有很多讓大家能覺得更好的調整.

我們盡量讓代碼能遵循特定的模式. 比如這個寫法在 JavaScript 很流行:

myPromise
  .then(() => {
    // ...
  })
  .then(() => {
    // ...
  })
  .catch(() => {
    // ..
  });

簡單的 printer 會把它折疊成下面這樣:

myPromise.then(() => {
  // ...
}).then(() => {
  // ...
}).catch(() => {
  // ..
});

不過在這場, 我們檢測到"鏈式調用"的模式然后特意把每個 .then 生成在獨立的一行.

如果你用到了某個 Prettier 沒有格式化好的模式, 請提交一個 Issue, 我們來討論一下如何檢測這個規則以及如何有針對性地處理你的場景.

在團隊中工作時, 很需要減少摩擦, 特別是在大型團隊里. 盡管無法完全避免摩擦, 我們更多能做的是通過工具變得更容易在一起協作.

你可能覺得配置一下 ESLint 不會消耗太多時間, 或者說團隊里不會話很多時間爭論語法. 根據我的經驗, 實際上不是. 即便你配置了大量的 ESLint 規則, 它實際上還是無法捕捉到全部的樣式的差異. 團隊仍然會努力去強制一套統一的樣式, 而這顯得很讓人分心.

語法的細節其實沒那么重要. 就讓 Prettier 這樣的工具來做格式和排版就好了, 程序員應該關注在那些真正的問題上.

結果好像的用了 Prettier 之后你寫代碼更加自由了, 怎么寫都可以, 因為隨后一格式化馬上就糾正回來了!

不想關心分號的問題? 當然, 直接寫就好了:

function foo() {
  var x = 5
  var y = 6
  var z = 7
  return x + y + z
}

把這段代碼貼到上面去, 你會看到 Prettier 已經幫你把分號插入好了.

處理特別復雜的問題的時候想要寫點臟代碼的? 當然可以, 全寫在一行都可以. 用自己習慣寫的臟的語法就好了. 然后只要一個快捷鍵就能把代碼格式化掉.

試一試 Prettier!

鳴謝:

Christopher Chedeau 鼓勵我把這些弄到能用的程度, 還有添加了 Jest 測試工具

Pieter Vanderwerff 在做相似的項目, 幫忙討論了解決方案

Jordan Walke 寫的 refmt, 也是 Prettier 的直接靈感來源