建站
咨詢
售后
建站咨詢
新聞中心
通過 Parser 把源碼解析成 AST 對象樹，源碼字符串中的各種信息就被保存到了這個(gè)對象樹里，然后遍歷 AST，對每一部分做檢查就能實(shí)現(xiàn) Lint 的功能，而自動 fix 的功能則是基于字符串替換實(shí)現(xiàn)的，指定某一段 range，替換成另一段文本即可。
超過十余年行業(yè)經(jīng)驗(yàn)，技術(shù)領(lǐng)先，服務(wù)至上的經(jīng)營模式，全靠網(wǎng)絡(luò)和口碑獲得客戶，為自己降低成本，也就是為客戶降低成本。到目前業(yè)務(wù)范圍包括了：成都網(wǎng)站設(shè)計(jì)、成都網(wǎng)站建設(shè)，成都網(wǎng)站推廣，成都網(wǎng)站優(yōu)化，整體網(wǎng)絡(luò)托管，成都微信小程序，微信開發(fā)，App定制開發(fā)，同時(shí)也可以讓客戶的網(wǎng)站和網(wǎng)絡(luò)營銷和我們一樣獲得訂單和生意！
說起來，Babel 也是基于 AST 實(shí)現(xiàn)的代碼分析和轉(zhuǎn)換，但是卻不能檢查和修復(fù)格式的問題，這是為什么呢?為什么 Eslint 可以檢查格式而 Babel 不可以呢?
我們先寫一個(gè) Eslint 的 rule
來感受下 Eslint 是怎么檢查和修復(fù)格式問題的。
Eslint 檢查格式的 rule大括號有兩種主流寫法，一種是同一行寫：
if (name === 'guang') {
}
另一種是新開一行寫：
if (name === 'guang')
{
}
我們寫一個(gè) eslint 的 rule 來檢查大括號的格式并自動修復(fù)成同一行的格式。
思路分析
Eslint 的檢查是基于 AST，我們要檢查的 AST 是塊語句 BlockStatement。
關(guān)于什么代碼是什么 AST 可以用 astexplorer.net 可視化的查看，parser 選擇 espree (Eslint 默認(rèn)的 parser)：
具體來說檢查的是 BlockStatement 的最開始的 token { 的行號，是不是和它前一個(gè) token 在同一行。(token 是指最小的不可再細(xì)分的單詞，比如關(guān)鍵字、變量名等標(biāo)識符、各種分隔符等)
如果是同一行，則說明了是符合規(guī)范的。當(dāng)然我們還可以進(jìn)一步檢查一下大括號 { 和前一個(gè) token 之間有沒有空格。
思路理清了，我們來寫下代碼：
代碼實(shí)現(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：實(shí)現(xiàn)對各種 AST 檢查的代碼，rule 的主體部分
我們在 create 里聲明了對 BlockStatement 節(jié)點(diǎn)的檢查，它的參數(shù)就是對應(yīng)的節(jié)點(diǎn)對象。
但是我們要檢查的是 token，這個(gè)用 context 里的一個(gè) 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 拿到了當(dāng)前 node 的開始 token，也就是 {，
然后又拿到了當(dāng)前 node 的前面一個(gè)節(jié)點(diǎn)的 token，也就是 (：
token 中保存了行列號信息，那么對比下行列號就知道是否有格式問題了：
如果 { 所在的行和 ) 所在的行不是同一行，就報(bào)錯(cuò)
if (firstToken.loc.start.line !== beforFirstToken.loc.start.line) {
context.report({
node,
loc: firstToken.loc,
message: '大括號格式不對'
});
}
修復(fù)的方式自然就是把 { 和 ) 之間的部分替換成一個(gè)空格，這個(gè)使用 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]], ' ');
}
});
}
同理，也可以檢查出 { 和 ) 之間沒有空格的格式錯(cuò)誤，修復(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]], ' ');
}
});
}
這樣就實(shí)現(xiàn)了大括號格式的檢查和自動修復(fù)。
我們來試下效果：
測試 rule
Eslint 除了提供命令行外，也提供了 api，我們調(diào)用它的 api 來測試 rule：
先創(chuàng)建 ESLint 對象，指定 rulePaths 也就是查找 rule 的目錄為當(dāng)前目錄：
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);
})();
我們來試一下效果:
三處格式錯(cuò)誤都檢查出來了!
然后把 fix 設(shè)為 true，來測試下自動修復(fù)：
格式自動修復(fù)了!
這樣我們就通過 Eslint 的 rule 實(shí)現(xiàn)了代碼格式的檢查和自動修復(fù)。
代碼上傳到了 github：https://github.com/QuarkGluonPlasma/eslint-plugin-exercize
那么再回到最開始的問題，為什么 Eslint 可以檢查代碼格式，而 Babel 不可以呢?
為什么 Eslint 可以檢查格式 Babel 不可以
我們寫了一個(gè)檢查大括號格式的 rule，可以發(fā)現(xiàn)能夠做格式檢查關(guān)鍵是能找到關(guān)聯(lián)的 token。
Eslint 的 AST 記錄了所有的 token，token 中有行列號信息，而且 AST 中也保存了 range，也就是當(dāng)前節(jié)點(diǎn)的開始結(jié)束位置。并且還提供了 SourceCode 的 api 可以根據(jù) range 去查詢 token。這是它能實(shí)現(xiàn)格式檢查的原因。
而 Babel 其實(shí)也支持 range 和 token，但是卻沒有提供根據(jù) range 查詢 token 的 api，這是它不能做格式檢查的原因。
其實(shí) Babel 和 Eslint 原理差不多，但是 Eslint 是被設(shè)計(jì)來做代碼錯(cuò)誤和格式檢查與修復(fù)的，而 Babel 是被設(shè)計(jì)用來做代碼分析和轉(zhuǎn)換的，目的不同，所以也就提供了不同的 api，能夠做不同的事情。
總結(jié)
Eslint 是用來檢查代碼中的錯(cuò)誤和格式問題的，基于 AST，Babel 也是基于 AST 做的代碼分析和轉(zhuǎn)換，但是卻不能檢查格式。
為了探究原因，我們寫了一個(gè) EsLint 的檢查大括號格式的 rule，通過 SourceCode 的 api 拿到 { 和 ( 的 token，對比下行列號來做檢查。并且通過 fixer 的字符串替換做了自動修復(fù)。
寫完之后，我們發(fā)現(xiàn) EsLint 能做格式檢查的原因是因?yàn)?AST 中記錄了 range，也保留了 token信息，并且提供了根據(jù) range 查詢 token 的 api，而 Babel 沒有。
EsLint 和 Babel 原理大同小異，但是有不同的設(shè)計(jì)目的，所以提供了不同的 api，有著不同的功能。
當(dāng)前名稱：為什么Eslint可以檢查和修復(fù)格式問題，而Babel
路徑分享：http://www.dlmjj.cn/article/djosgsg.html
