一千个读者，就有一千个哈姆雷特。对于一千个程序员，有一千种编码风格。那么什么是代码风格呢？从小到大，有的开发者喜欢用分号，有的不喜欢用分号。有些喜欢使用空格，有些喜欢使用制表符。有些像两个空格，有些像四??个空格。除了这些，还有一些代码优化，比如避免无用的声明，避免冗余的代码逻辑等。如果你刚入职，恰好遇到代码风格混乱，赋值密集，前后没有空格的项目，你只能有苦难。因此，团队合作需要统一的规范。ESLint和ConstrainedUnifiedCodingStandards不仅可以大大提高代码的可读性，甚至可以提高代码质量。当我们设计一套关于编码标准的规则时，我们需要工具来辅助检测，这就是ESLint。$npminstalleslint--save-dev规则集需要集中配置。ESLint默认会读取配置文件.eslintrc进行解析，规则集在rules中配置：{"rules":{"semi":["error","always"],"quotes":["error","double"]}}我们要做的就是设置我们的代码规范，也就是规则项。不要重新发明轮子。是否需要重新设计一套属于自己团队的编码标准？没有必要一遍又一遍地开始。它是劳动密集型的，并且很难涵盖所有规则。许多优秀的团队都根据最佳实践制定了特别优秀的编码标准。例如，airbnb制定了一套特别严格的标准。还有一些非常简单但非常有用的规范，例如eslint:recommended。airbnbjavascriptstyle[2]我们只需要使用extend配置项就可以继承一些优秀的开源代码规范，使用rules为自己的团队做一些规则补充。{"extend":["airbnb-base"],"rules":{"semi":["error","never"]}}开发环境、生产环境和warning开发环境什么对开发重要？是开发经验。良好的编码规范会带来解放强迫症的舒适感，但过于严格的代码风格有时会让人烦躁。给大家举两个小例子，写代码的时候可能出现过：禁用console.log，避免在生产环境输出多余的东西。但是往往需要在测试环境中进行调试，但是如果只设置为警告，警告就会被忽略而失去意义。特别是当设置了no-unused-vars规则时。如果只是为了开发时的调试，由于无法通过ESlint规则校验，所以无法轻松调试。这是约束和自由之间的权衡。ESLint在提供强约束的同时，自然会牺牲一些开发便利性。中庸之道，儒家讲究中庸之道。这时候你可以权衡下选择一个适度的方案：将所有影响调试的ESLint规则检查设置为Warn，那你又问了，warnings不会被忽略吗？是这样的，所以需要在CI中设置环境变量CI=true，这样即使CI中有警告也无法投递。例如，create-react-app中的大部分规则都设置为Warn。但是，如果使用webpack并结合eslint-loader，解决方案就更简单了：使用emitWarning:true，将测试环境中的所有Error都当成Warn处理，这样就避免了修改ESLint规则。webpack的配置如下：{test:/\.(js|mjs|jsx|ts|tsx)$/,enforce:'pre',use:[{options:{cache:true,emitWarning:true,},loader:require.resolve('eslint-loader'),},]}所以有两种方法可以平衡开发体验和编程标准：设置ESLint的rule为Warnandcontinue中配置环境变量CI=true一体化。结合webpack和eslint-loader，根据当前环境的环境变量配置emitWarning。第一层约束：当IDE不符合代码规范时，我们要感知到，及时反馈，迅速改正，这比错误累积到最后要高效得多。这里以VSCode为例，只需要安装一个插件：eslint，就可以实现智能提示，来看看效果：另外，配合eslint-loader，还可以使用浏览器实现实时提示：第二层约束：GitHooksteamwork中的编码标准之一是，虽然你可能不舒服，但你不能因为你自己的代码而让别人感到不舒服。Git本身包含很多hooks，在commit、push等git事件前后触发。结合pre-commithook可以帮助验证Lint，如果代码规范不通过，则不允许提交。husky[3]是一个让githooks更容易的工具。只需要配置几行package.json就可以愉快的开始工作了。(1)哈士奇的原理是什么？//package.json{"scripts":{"lint":"eslint.--cache"},"husky":{"hooks":{"pre-commit":"npmlint",}}}或结合lint-staged[4]调用验证规则{"husky":{"hooks":{"pre-commit":"lint-staged"}},"lint-staged":{"*.js|{lib,setup,bin,hot,tooling,schemas}/**/*.js|test/*.js|{test,examples}/**/webpack.config.js}":["eslint--cache"],"*.{ts,json,yml,yaml,md}|examples/*.md":["prettier--check"],"*.md|{.github,benchmark,bin,examples,hot,lib,schemas,setup,tooling}/**/*.{md,yml,yaml,js,json}":["cspell"]}}但是做前端的都懂，client-sidecalibration验证是不可信的，并且githooks可以通过一个命令绕过。$gitcommit-n第三层约束：CIgithooks可以绕过，但是CI（持续集成）是绝对绕不过去的，因为是在服务端验证的。使用gitlabCI进行持续集成，配置文件.gitlab-ci.yaml如下：lint:stage:lintonly:-/^feature\/.*$/script:-npmlint总结团队中的代码标准化是极其必要的使用成熟的eslintconfig，并进行细致的修改，将一些eslint规则设置为警告，以保证开发体验，在pre-commit和CI中将警告视为失败，以确保在IDE（vscode）、githooks中可以使用严格的代码规范,在CI中加入标准验证拦截可以使用husky和lint-staged轻松做关于lint的githooks。githooks的标准校验可以通过gitcommit-n跳过，需要继续加强CI层的校验
