用「增量」思想提升代码检查和打包构建的效率

一.引子

在这里「增量」这个概念的对立面是「全量」。在 Linux 系统中当需要备份数据或者跨服务器同步文件时，会用到一个叫 rsync 的工具，它的速度会比 scp/cp 命令更快，因为它会先判断已经存在的数据和新数据的差异，只传输不同的部分，即「增量」同步。

在前端开发工程化领域，本文将介绍用「增量」思想提升代码检查、打包构建环节的速度，从而实现开发过程的效率提升。

二.增量代码检查

前端使用 ESLint 做代码规范静态检查。随着前端工程化的发展，我们会将代码检查与开发工作流集成，在代码提交前和代码交付前自动做 ESLint 检查。代码提交检查即在开发者每一次 commit 时通过 git hooks 触发 ESLint 检查，当工程代码量很大时开发者每一次提交代码甚至要等数分钟时间才能检查完。代码交付检查即借助持续集成流程，比如在 MR 时触发代码检查，这是会阻断 MR 的流程的，经常会出现这样一种情况，某个 MR 仅仅修改了一行代码，却要扫瞄整个项目，这会严重影响持续集成的效率。所以大部分情况下并不需要进行 ESLint 的全量扫描，我们更关心的是新增代码是否存在问题。

接下来我们通过自定义 git 的 pre-commit 钩子脚本来为一个工程实现增量代码提交检查能力。

2.1 寻找修改的文件

本脚本中 ESLint 检查执行到文件这一粒度。实现增量代码检查首先就是要能找到增量代码，即修改了哪些文件。我们借助 git 版本管理工具寻找提交时暂存区和 HEAD 之间的差异，找到修改的文件列表。

1. 使用 git diff 找到本次提交修改的文件，加 --diff-filter=ACMR 参数是为了去掉被删除的文件，删除的文件不需要再做检查了；
2. 使用 child_process 模块的 exec 函数在 node 中执行 git 的命令；
3. 输出的是由修改的文件组成的字符串，做简单的字符串处理提取出要检查的文件列表；

const exec = require('child_process').exec;
const GITDIFF = 'git diff --cached --diff-filter=ACMR --name-only';
// 执行 git 的命令
exec(GITDIFF, (error, stdout) => {
    if (error) {
        console.error(`exec error: ${error}`);
    }
    // 对返回结果进行处理，拿到要检查的文件列表
    const diffFileArray = stdout.split('\n').filter((diffFile) => (
        /(\.js|\.jsx)(\n|$)/gi.test(diffFile)
    ));
    console.log('待检查的文件：', diffFileArray);
});

2.2 对被修改的文件进行代码检查

ESLint 提供了同名类函数（ESLint）作为 Node.js API 调用（低于 7.0.0 版本使用 CLIEngine 类），这样我们能在 node 脚本中执行代码检查并拿到检查结果。

1. 使用 ESLint 的 lintFiles 函数对文件列表进行代码检查；
2. 返回的结果是个数组，包含每个文件的检查结果，对数组进行处理拿到检查结果并输出提示；

const { ESLint } = require('eslint');
const linter = new ESLint();

// 上文拿到待检查的文件列表后

let errorCount = 0;
let warningCount = 0;
if (diffFileArray.length > 0) {
    // 执行ESLint代码检查
    const eslintResults = linter.lintFiles(diffFileArray).results;
    // 对检查结果进行处理，提取报错数和警告数
    eslintResults.forEach((result) => {
        // result的数据结构如下：
        // {
        //     filePath: "xxx/index.js",
        //     messages: [{
        //         ruleId: "semi",
        //         severity: 2,
        //         message: "Missing semicolon.",
        //         line: 1,
        //         column: 13,
        //         nodeType: "ExpressionStatement",
        //         fix: { range: [12, 12], text: ";" }
        //     }],
        //     errorCount: 1,
        //     warningCount: 1,
        //     fixableErrorCount: 1,
        //     fixableWarningCount: 0,
        //     source: "\"use strict\"\n"
        // }
        errorCount += result.errorCount;
        warningCount += result.warningCount;
        if (result.messages && result.messages.length) {
            console.log(`ESLint has found problems in file: ${result.filePath}`);
            result.messages.forEach((msg) => {
                if (msg.severity === 2) {
                    console.log(`Error : ${msg.message} in Line ${msg.line} Column ${msg.column}`);
                } else {
                    console.log(`Warning : ${msg.message} in Line ${msg.line} Column ${msg.column}`);
                }
                
            });
        }
    });
}

2.3 友好的提示及错误处理

1. 在命令行界面做友好的输出提示，本次代码检查是否通过；
2. 如果检查结果存在错误，就以非 0 值退出，git 将放弃本次提交。

if (errorCount >= 1) {
    console.log('\x1b[31m', `ESLint failed`);
    console.log('\x1b[31m', `✖ ${errorCount + warningCount} problems(${errorCount} error, ${warningCount} warning)`);
    process.exit(1);
} else if (warningCount >= 1) {
    console.log('\x1b[32m', 'ESLint passed, but need to be improved.');
    process.exit(0);
} else {
    console.log('\x1b[32m', 'ESLint passed');
    process.exit(0);
}

到这里 pre-commit 钩子脚本就完成了，只需要在 package.json 文件中配置下脚本的执行就能实现增量代码检查了。最终实现的效果是开发者在提交代码时再也不用等待全量代码检查完成了，脚本会很快找到有改动的文件并检查完。

如果想要在自己的项目中实现这一功能，可以直接使用开源库 lint-staged 结合 husky 一起用。

代码交付时的增量检查实现方式和上面的步骤类似，关键点就是找到增量的部分。