摘要：原文今天我發(fā)布一個(gè)格式化工具它的靈感來(lái)源于它對(duì)于和的語(yǔ)言特性有著高級(jí)的支持通過(guò)將解析為并且基于美化和打印會(huì)丟掉幾乎全部的原始的代碼風(fēng)格從而保證代碼風(fēng)格的一致性跟不一樣的在于它沒(méi)有大量的和需要管理不過(guò)同時(shí)有一點(diǎn)也很重要一切都是確定好的我很高

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

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

下面是一個(gè)在線運(yùn)行的 Demo. 注意語(yǔ)法是支持 JSX 和 Flow 的. 你可以在下面的編輯器里輸入任何代碼, 代碼會(huì)被自動(dòng)格式化.
行長(zhǎng)的最大值是 60. 兩個(gè)編輯器當(dāng)中上面一個(gè)是原始輸入, 下面是格式化之后的版本.

//                                           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 運(yùn)行在 Prettier 0.0.8)

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

大概在同時(shí)我用了一段時(shí)間 Reason, Reason 提供了 refmt 工具用來(lái)自動(dòng)格式化代碼. 我就被迷住了. refmt 屏蔽了寫(xiě)代碼當(dāng)中很多讓人分心的因素. 你可以按自己的習(xí)慣隨便寫(xiě), 然后格式化掉. 我意識(shí)到這不僅可以解決 JSX 的問(wèn)題, 它也可以對(duì)任何編輯器提供強(qiáng)制整個(gè)團(tuán)隊(duì)代碼樣式的一致性的工具.

如果說(shuō)計(jì)算機(jī)擅長(zhǎng)做某個(gè)事情的話, 計(jì)算機(jī)會(huì)擅長(zhǎng)解析代碼和分析代碼. 所以我準(zhǔn)備把這個(gè)事情做出來(lái), 這樣就有了 Prettier. 我并不打算從底層開(kāi)始寫(xiě), 所以 Prettier 是從 fork recast 的 printer 開(kāi)始的, 內(nèi)部用 Wadler 在 "A prettier printer" 的算法進(jìn)行了重寫(xiě).

為什么選這套算法? 首先要看下為什么已有的樣式格式化工具并沒(méi)有實(shí)際的效驗(yàn).

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

比如看下面的代碼:

foo(arg1, arg2, arg3);

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

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

我之前的格式突然就不正常了, 因?yàn)樘L(zhǎng)了. 你多半會(huì)這樣來(lái)處理:

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

這個(gè)例子清楚地展出了最大行長(zhǎng)對(duì)于我們想要的代碼的樣式有著直接的影響. 目前的樣式工具無(wú)視了這一點(diǎn), 也就意味著在這個(gè)麻煩的場(chǎng)景當(dāng)中它們毫無(wú)幫助. 團(tuán)隊(duì)里的每個(gè)人會(huì)按照他們自己不一樣的規(guī)則調(diào)整代碼的樣式, 因而我們也就失去了我們想要的一致性.

Wadler 算法的論文描述了基于約束的代碼的局部系統(tǒng). 它會(huì)"測(cè)算"代碼的長(zhǎng)度, 如果超過(guò)了最大行長(zhǎng), 就會(huì)折行.

即便我們不顧行長(zhǎng), 在各種 linter 工具里也有很多辦法偷懶. 我所知道的最嚴(yán)格的 linter 也會(huì)讓這樣代碼的代碼通過(guò):

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

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

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

Prettier 通過(guò)解析代碼和基于 AST 重新生成滿足自己的規(guī)則的代碼, 計(jì)算考慮了最大行長(zhǎng), 必要時(shí)進(jìn)行代碼的折行, 最終屏蔽了各種過(guò)于自由的樣式.

為了讓 Prettier 變得實(shí)用我做了大量的工作. 目前輸出的代碼已經(jīng)不錯(cuò)了, 我估計(jì)后面還有很多讓大家能覺(jué)得更好的調(diào)整.

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

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

簡(jiǎn)單的 printer 會(huì)把它折疊成下面這樣:

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

不過(guò)在這場(chǎng), 我們檢測(cè)到"鏈?zhǔn)秸{(diào)用"的模式然后特意把每個(gè) .then 生成在獨(dú)立的一行.

如果你用到了某個(gè) Prettier 沒(méi)有格式化好的模式, 請(qǐng)?zhí)峤灰粋€(gè) Issue, 我們來(lái)討論一下如何檢測(cè)這個(gè)規(guī)則以及如何有針對(duì)性地處理你的場(chǎng)景.

在團(tuán)隊(duì)中工作時(shí), 很需要減少摩擦, 特別是在大型團(tuán)隊(duì)里. 盡管無(wú)法完全避免摩擦, 我們更多能做的是通過(guò)工具變得更容易在一起協(xié)作.

你可能覺(jué)得配置一下 ESLint 不會(huì)消耗太多時(shí)間, 或者說(shuō)團(tuán)隊(duì)里不會(huì)話很多時(shí)間爭(zhēng)論語(yǔ)法. 根據(jù)我的經(jīng)驗(yàn), 實(shí)際上不是. 即便你配置了大量的 ESLint 規(guī)則, 它實(shí)際上還是無(wú)法捕捉到全部的樣式的差異. 團(tuán)隊(duì)仍然會(huì)努力去強(qiáng)制一套統(tǒng)一的樣式, 而這顯得很讓人分心.

語(yǔ)法的細(xì)節(jié)其實(shí)沒(méi)那么重要. 就讓 Prettier 這樣的工具來(lái)做格式和排版就好了, 程序員應(yīng)該關(guān)注在那些真正的問(wèn)題上.

結(jié)果好像的用了 Prettier 之后你寫(xiě)代碼更加自由了, 怎么寫(xiě)都可以, 因?yàn)殡S后一格式化馬上就糾正回來(lái)了!

不想關(guān)心分號(hào)的問(wèn)題? 當(dāng)然, 直接寫(xiě)就好了:

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

把這段代碼貼到上面去, 你會(huì)看到 Prettier 已經(jīng)幫你把分號(hào)插入好了.

處理特別復(fù)雜的問(wèn)題的時(shí)候想要寫(xiě)點(diǎn)臟代碼的? 當(dāng)然可以, 全寫(xiě)在一行都可以. 用自己習(xí)慣寫(xiě)的臟的語(yǔ)法就好了. 然后只要一個(gè)快捷鍵就能把代碼格式化掉.

試一試 Prettier!

鳴謝:

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

Pieter Vanderwerff 在做相似的項(xiàng)目, 幫忙討論了解決方案

Jordan Walke 寫(xiě)的 refmt, 也是 Prettier 的直接靈感來(lái)源