一个项目往往不只一个人开发，多人合作自然需要版本控制来合理管理代码，比如 git、svn 等。个人喜欢 git，以及直男社区 github。git 除了能管理代码版本，还可以在 npm script 里运用，不然我也不会在这啰嗦那么多做铺垫了。git 在 npm script 的运用主要体现在 pre 和 post 的钩子上，也就是大家熟知的 git hooks，能帮助我们在代码提交（commit）和获取时（push）做一些事情。

说说场景

本地仓库配置 pre-commit 和 pre-push，是给要提交的代码做检查；
远程仓库配置 pre-receive，是给拉取下来的代码做检查，以确保符合本地代码规范，假如没有这步，本地开发者偷懒使用 --no-verify（或-n）就可以规避本地代码检查；

注：有些懒可以偷，有些不可以。有些懒，虽一时方便了自己，但长远来看，不仅是坑了自己，更是坑了整个团队。

全面检查

全面检查，就是对匹配文件的全量遍历。

前端社区中 npm script 结合 git-hooks 的方案，个人还是喜欢 husky，就是好用嘛，而且还支持跟多的 git hooks 工具，比如后面要说的 lint-staged。还等什么 =>

安装依赖包

npm install husky -D
// 或
yarn add husky -D

编写

{   
    "scripts": {
        "lint:js": "# 检查 js \n  eslint ./src/**/*.js",
        "test": "# 单元测试 \n cross-env NODE_ENV=test mocha tests/"
    },
    "husky": {
        "hooks": {
            "pre-commit": "npm run lint:js",
            "pre-push": "npm run test"
        }
    },
}

剖析

1.安装依赖包 husky 后，可查看 .git/hooks 目录，都是 husky 的钩子

执行

1.代码开发完毕，准备提交到本地仓库

git commit -am "git hooks 的使用"

此时会调用 pre-commit，发现错误：

2.解决了有错误的 request.js 问题，提交到远程分支上，又发现单元测试环节出现了问题：

3.解决单元测试错误就能提交到远程分支仓库了

搭载 `lint-staged` 让你飞

以上基本实现我们所需要的，但是...现实的情况是，有些场景我们会接手他人项目，如果按上面步骤走，每次提交代码就会检查所有代码（上面例子只检查 js 的代码）就会发现有 n 个文件有警告或错误（成百上几个），瞬间处于崩溃边缘，想重构或跑路节奏。

lint-staged 当然就是帮助我们解决这类场景问题的，加上 prettier 如虎添翼。

安装依赖包

npm install lint-staged prettier -D
// 或
yarn add lint-staged prettier -D

编写

{
    "scripts": {
        "lint:js": "# 检查 js \n  eslint ./src/**/*.js",
        "test": "# 单元测试 \n cross-env NODE_ENV=test mocha tests/"
    },
    "husky": {
        "hooks": {
            "pre-commit": "lint-staged",
            "pre-push": "npm run test"
        }
    },
    "lint-staged": {
        "linters": {
            "src/**/*.js": [
                "prettier --tab-width 4 --write",
                "eslint --fix",
                "git add"
            ],
            "src/**/*.{css, less}": [
                "prettier --tab-width 4 --write",
                "stylelint --fix",
                "git add"
            ]
        },
        "ignore": [
            "**/dist/*.min.js"
        ]
    }
}

剖析

lint-staged 是一个前端文件过滤工具，不会格式化任何东西，没有代码规则配置文件，需要自己配置；
lint-staged 它的作用是指检查当前改动的文件（或者说当次要提交到本地仓库的文件）;
pre-commit 钩子启动会执行 lint-staged 命令，然后对本次 commited 中的所有 .js 和 .{less, css} 文件执行 exlint --fix 、 stylelint --fix 和 git add;
prettier 代码格式优化，它能优化 js, jsx, ts, css, less, scss, json, md, ...，保证团队代码风格是相当有用的。

如果，你嫌lint-staged 写在 package.json 臃肿，可以抽取出来放到 .lintstagedrc 中：

{
    "linters": {
      "src/**/*.js": [
        "prettier --tab-width 4 --write",
        "eslint --fix",
        "git add"
      ],
      "src/**/*.{css, less}": [
        "prettier --tab-width 4 --write",
        "stylelint --fix",
        "git add"
      ]
    },
    "ignore": [
      "**/dist/*.min.js"
    ]
}

执行

git commit -am "本次提交解释说明"

假如 src/utils 目录下有 request.js 和 index.js 两个文件，其中两个文件代码都有错误，但是 index.js 是别人写的，属于历史版本（之前怎么提交到仓库或许是因为没做检查或者跳过检查了吧）。本次其实只改动了 request.js 文件，如果按照前面步骤，就会检查出两个文件都有问题，而这又不是我们想要的，因为 index.js 文件不是我写的，里面的代码不好改动（业务逻辑和功能逻辑不明白），这个时候，lint-staged 的价值就提现出来了，只报出 request.js 文件的错误（知我者）：

多几句嘴

现在可以在你的项目中应用起来了，还等什么！！！

你可以...

上一篇：npm script 复杂场景的应用

下一篇：npm script 的实践

目录：npm script 小书