Eslint 可以檢查出代碼中的錯誤和一些格式問題，并能自動修復(fù)，它的實現(xiàn)原理就是基于 AST (抽象語法樹)。

通過 Parser 把源碼解析成 AST 對象樹，源碼字符串中的各種信息就被保存到了這個對象樹里，然后遍歷 AST，對每一部分做檢查就能實現(xiàn) Lint 的功能，而自動 fix 的功能則是基于字符串替換實現(xiàn)的，指定某一段 range，替換成另一段文本即可。

說起來，Babel 也是基于 AST 實現(xiàn)的代碼分析和轉(zhuǎn)換，但是卻不能檢查和修復(fù)格式的問題，這是為什么呢?為什么 Eslint 可以檢查格式而 Babel 不可以呢?

我們先寫一個 Eslint 的 rule

來感受下 Eslint 是怎么檢查和修復(fù)格式問題的。

Eslint 檢查格式的 rule大括號有兩種主流寫法，一種是同一行寫：

if (name === 'guang') {
}

另一種是新開一行寫：

if (name === 'guang')
{
}

我們寫一個 eslint 的 rule 來檢查大括號的格式并自動修復(fù)成同一行的格式。

思路分析

Eslint 的檢查是基于 AST，我們要檢查的 AST 是塊語句 BlockStatement。

關(guān)于什么代碼是什么 AST 可以用 astexplorer.net 可視化的查看，parser 選擇 espree (Eslint 默認的 parser)：

具體來說檢查的是 BlockStatement 的最開始的 token { 的行號，是不是和它前一個 token 在同一行。(token 是指最小的不可再細分的單詞，比如關(guān)鍵字、變量名等標識符、各種分隔符等)

如果是同一行，則說明了是符合規(guī)范的。當然我們還可以進一步檢查一下大括號 { 和前一個 token 之間有沒有空格。

思路理清了，我們來寫下代碼：

代碼實現(xiàn)

Eslint 的 rule 的格式是這樣的：

 module.exports = {
     meta: {
         docs: {
             description: "enforce consistent brace style for blocks"
         },

         fixable: true
     },
 
     create(context) {
         return {
            BlockStatement(node) {
            }
        }
    }
 };

分為 meta 和 create 兩部分：

• meta：描述各種元信息，比如文檔描述、是否可自動修復(fù)等
• create：實現(xiàn)對各種 AST 檢查的代碼，rule 的主體部分

我們在 create 里聲明了對 BlockStatement 節(jié)點的檢查，它的參數(shù)就是對應(yīng)的節(jié)點對象。

但是我們要檢查的是 token，這個用 context 里的一個 api：

create(context) {
     const sourceCode = context.getSourceCode();
     return {
        BlockStatement(node) {
            const firstToken = sourceCode.getFirstToken(node);
            const beforFirstToken = sourceCode.getTokenBefore(node);
        }
     }
}

我們從 context 中拿到了 sourceCode 的 api，它就是用來取 token 的。

我們用 getFirstToken 拿到了當前 node 的開始 token，也就是 {，

然后又拿到了當前 node 的前面一個節(jié)點的 token，也就是 (：

token 中保存了行列號信息，那么對比下行列號就知道是否有格式問題了：

如果 { 所在的行和 ) 所在的行不是同一行，就報錯

if (firstToken.loc.start.line !== beforFirstToken.loc.start.line) {
    context.report({
        node,
        loc: firstToken.loc,
        message: '大括號格式不對'
    });
} 

修復(fù)的方式自然就是把 { 和 ) 之間的部分替換成一個空格，這個使用 fixer 提供的 api：replaceTextRange：

if (firstToken.loc.start.line !== beforFirstToken.loc.start.line) {
    context.report({
        node,
        loc: firstToken.loc,
        message: '大括號格式不對'
        fix: fixer => {
            return fixer.replaceTextRange([beforFirstToken.range[1], firstToken.range[0]], ' ');
        }
    });
} 

同理，也可以檢查出 { 和 ) 之間沒有空格的格式錯誤，修復(fù)方式一樣：

if (firstToken.loc.start.column === beforFirstToken.loc.start.column + 1){
    context.report({
        node,
        loc: firstToken.loc,
        message: '大括號前缺少空格',
        fix: fixer => {
            return fixer.replaceTextRange([beforFirstToken.range[1], firstToken.range[0]], ' ');
        }
    });
}

這樣就實現(xiàn)了大括號格式的檢查和自動修復(fù)。

我們來試下效果：

測試 rule

Eslint 除了提供命令行外，也提供了 api，我們調(diào)用它的 api 來測試 rule：

先創(chuàng)建 ESLint 對象，指定 rulePaths 也就是查找 rule 的目錄為當前目錄：

const { ESLint } = require("eslint");

const engine = new ESLint({
    fix: false,
    overrideConfig: {
        parserOptions: {
            ecmaVersion: 6,
        },
        rules: {
            'my-brace-style': ['error']
        }
    },
    rulePaths: [__dirname],
    useEslintrc: false
});

useEslintrc 為 false 是不查找配置文件， fix 為 false 是不自動修復(fù)。

然后調(diào)用它的 lintText 代碼來測試，返回的結(jié)果使用 formatter 打?。?/p>

(async function main() {
    const results = await engine.lintText(`
        if (print) 
        {
            const num = a + b;
            console.log(num);
        }
        for(let i = 0;i<100;i++)
        {
            console.log(i);
        }
  `);
  
    console.log(results[0].output);
  
    const formatter = await engine.loadFormatter("stylish");
    const resultText = formatter.format(results);
    console.log(resultText);
  })();

我們來試一下效果:

三處格式錯誤都檢查出來了!

然后把 fix 設(shè)為 true，來測試下自動修復(fù)：

格式自動修復(fù)了!

這樣我們就通過 Eslint 的 rule 實現(xiàn)了代碼格式的檢查和自動修復(fù)。

代碼上傳到了 github：https://github.com/QuarkGluonPlasma/eslint-plugin-exercize

那么再回到最開始的問題，為什么 Eslint 可以檢查代碼格式，而 Babel 不可以呢?

為什么 Eslint 可以檢查格式 Babel 不可以

我們寫了一個檢查大括號格式的 rule，可以發(fā)現(xiàn)能夠做格式檢查關(guān)鍵是能找到關(guān)聯(lián)的 token。

Eslint 的 AST 記錄了所有的 token，token 中有行列號信息，而且 AST 中也保存了 range，也就是當前節(jié)點的開始結(jié)束位置。并且還提供了 SourceCode 的 api 可以根據(jù) range 去查詢 token。這是它能實現(xiàn)格式檢查的原因。

而 Babel 其實也支持 range 和 token，但是卻沒有提供根據(jù) range 查詢 token 的 api，這是它不能做格式檢查的原因。

其實 Babel 和 Eslint 原理差不多，但是 Eslint 是被設(shè)計來做代碼錯誤和格式檢查與修復(fù)的，而 Babel 是被設(shè)計用來做代碼分析和轉(zhuǎn)換的，目的不同，所以也就提供了不同的 api，能夠做不同的事情。

總結(jié)

Eslint 是用來檢查代碼中的錯誤和格式問題的，基于 AST，Babel 也是基于 AST 做的代碼分析和轉(zhuǎn)換，但是卻不能檢查格式。

為了探究原因，我們寫了一個 EsLint 的檢查大括號格式的 rule，通過 SourceCode 的 api 拿到 { 和 ( 的 token，對比下行列號來做檢查。并且通過 fixer 的字符串替換做了自動修復(fù)。

寫完之后，我們發(fā)現(xiàn) EsLint 能做格式檢查的原因是因為 AST 中記錄了 range，也保留了 token信息，并且提供了根據(jù) range 查詢 token 的 api，而 Babel 沒有。

EsLint 和 Babel 原理大同小異，但是有不同的設(shè)計目的，所以提供了不同的 api，有著不同的功能。