关于前端:VSCode-中前端代码规范和编码风格实践详解

本文以 VS Code 编辑器为例开展，能够搭配 vscode-linter-example 这个例子对照着实际一下。

文章开始之前首先思考一个问题：缩进的代码格调到底是 2 个空格还是 4 个空格是受谁管制的？VS Code 默认设置？还是 Prettier? 或者其余什么？

带着问题开始本文吧。

VS Code 的配置有三种模式：全局默认配置、用户配置、工作区配置。

全局默认配置：VS Code 在装置实现后，在装置目录会有一个 settings.json 配置文件。
用户配置：对应的是软件目录中跟以后用户相关联的特定文件夹中的 settings.json 配置文件（相似于 macOS 中 $HOME/Library/Application Support/Code/User/settings.json），用户配置在所有关上窗口都失效。通过 ctrl/cmd + , 关上的设置就是用户配置 settings.json 的 UI 视图。
工作区配置：也称我的项目配置，此时的 settings.json 寄存于我的项目所在根目录的 .vscode 文件中，当我的项目在 VS Code 中关上时，仅针对以后我的项目关上的窗口失效。

这三种模式的配置优先级：我的项目配置 > 用户配置 > 全局默认配置。

如果存在多种配置，那么优先级高的会笼罩优先级低的，这样的益处是能够为不同我的项目、不同用户做不同配置，而不会互相烦扰，并且我的项目配置特定于我的项目，不便开发人员之间共享，达到对立开发环境和编码格调的目标。

VS Code 的 `.vscode` 文件夹

我的项目根目录中的.vscode 文件夹，除了寄存我的项目配置，还有其余的配置。

.vscode 文件夹下蕴含的配置：

settings.json
extensions.json
tasks.json
launch.json

`settings.json`

能够在这个我的项目配置文件中利用编辑器本身默认格式化程序来进行编码格调对立，这也是最根本的格式化。

{
  "editor.formatOnSave": true, // 保留时主动格式化代码
  // 依据关上文件的内容自动检测缩进，会笼罩默认缩进设置，相干设置：#editor.tabSize# 和 #editor.intertSpaces#
  // 例如尽管上面设置的 tabSize 为 4，然而以后文件关上时是文件内容的 tabSize 为 2，所以仍然会沿用 2，如果设置为 false，后续的 tabSize 则会应用 4
  "editor.detectIndentation": false,
  "editor.insertSpaces": true, // 是否应用空格
  "editor.tabSize": 4, // 空格或者制表符的大小
  "editor.fontSize": 14, // 编辑器字体大小
  "editor.rulers": [80, 100], // 垂直标尺，会在指定列号处显示竖线
  "editor.wordWrap": "wordWrapColumn", // 管制换行形式
  "editor.wordWrapColumn": 100 // 管制换行的宽度
}

我的项目开发中，有些生成的两头文件或者有一些不心愿我的项目一般开发者改变的配置文件等，就能够在 settings.json 中配置，屏蔽这些文件。

{
  // 搜寻文件时不心愿查找的文件
  "search.exclude": {
    "**/node_modules": true,
    "**/bower_components": true,
    "**/*.code-search": true
  },
  // 不想展现的文件
  "files.exclude": {
    "**/.git": true,
    "**/build": true,
    "**/deploy.sh": true
  }
}

{
  // 额定补充一下，VS Code 默认反对 TS，并且能够切换应用我的项目装置的 TypeScript 版本提供的语法解析和类型检测服务
  "typescript.tsdk": "node_modules/typescript/lib"
}

`extensions.json`

后续会用到的 eslint 和 prettier 插件能够间接增加在 extensions.json，不便其余开发人员装置。

{
  // 每一项都是一个插件 ID
  "recommendations": [
    "dbaeumer.vscode-eslint", // eslint 插件 ID，上面会讲到此插件
    "esbenp.prettier-vscode", // prettier 插件 ID，上面会讲到此插件
    "EditorConfig.EditorConfig", // EditorConfig 插件 ID，上面会讲到此插件
    "octref.vetur",
    "formulahendry.auto-close-tag",
    "formulahendry.auto-rename-tag"
  ]
}

配置实现后，我的项目开发者在第一次关上我的项目的时候会收到 VS Code 的举荐揭示，能够进行一键装置。如果错过了这次揭示，在侧边栏的插件选项中，也能够筛选出举荐插件进行一键装置。

对于工作相干 `tasks.json` 和调试相干的 `launch.json`，后续有机会再聊。

EditorConfig 是用来帮忙开发者定义和保护编码格调的（例如缩进款式，行尾字符等），EditorConfig 蕴含一个用于定义代码格局的自定义文件 .editorconfig 和一批编辑器插件，这些插件是让编辑器可能应用自定义配置文件并以此来格式化代码。

应用了 EditorConfig 后，编辑器的行为会与 .editorconfig 文件中定义的统一，并且其优先级比编辑器本身的设置要高（比上一大节讲到的 VS Code 本身配置优先级高）。有些编辑器默认反对 EditorConfig，如 WebStorm；而有些编辑器则须要装置 EditorConfig 插件，如 Sublime、VS Code 等（所以说能够跨编辑器失效）。

VS Code 装置非常简单，间接在插件市场搜寻 EditorConfig for VS Code 装置而后重启编辑器。

当关上一个文件时，EditorConfig 插件会在关上文件的目录和其每一级父目录查找 .editorconfig 文件，直到有一个配置文件呈现 root=true。

EditorConfig 的配置文件是从上往下读取的，并且最近的 .editorconfig 会被最先读取，匹配 .editorconfig 中的配置项会依照读取程序被利用，如果 .editorconfig 文件没有进行某些配置，则应用编辑器默认的设置。

配置 `.editorconfig`

文件名匹配：

*                匹配除 / 之外的任意字符串
**               匹配任意字符串
?                匹配任意单个字符
[name]           匹配 name 字符
[!name]          不匹配 name 字符
{s1,s2,s3}       匹配给定的字符串中的任意一个(用逗号分隔)
{num1..num2}    匹配 num1 到 num2 之间的任意一个整数, 这里的 num1 和 num2 能够为正整数也能够为负整数

罕用属性：

root :           示意是最顶层的配置文件，发现设为 true 时，才会进行查找下级的.editorconfig 文件
indent_style :    设置缩进格调(tab 是硬缩进，space 为软缩进)
indent_size :     用一个整数定义的列数来设置缩进的宽度，如果 indent_style 为 tab，则此属性默认为 tab_width
tab_width :       用一个整数来设置 tab 缩进的列数。如果 indent_style 为 space，默认是 indent_size
end_of_line :     设置换行符，值为 lf、cr 和 crlf
charset :         设置编码，值为 latin1、utf-8、utf-8-bom、utf-16be 和 utf-16le，不倡议应用 utf-8-bom
trim_trailing_whitespace :  设为 true 示意会去除行尾空格
insert_final_newline :      设为 true 示意使文件以一个空白行结尾
max_line_length：最大行宽（vscode 不反对）curly_bracket_next_line：设为 false 示意大括号不另起一行（vscode 不反对）spaces_around_operators：设为 true 运算符两边都有空格（vscode 不反对）quote_type :                设置字符串的引号类型，single 是单引号,double 是双引号（vscode 不反对）

装置完 EditorConfig 插件，并且创立并欠缺了 .editorconfig 自定义规定，此时，.editorconfig 中的规定会笼罩 VS Code user/workspace settings 中对应的配置。

例如一个示例 .editorconfig：

root = true

[*]
charset = utf-8

[*.{js,jsx,ts,tsx,vue}]
indent_style = space
indent_size = 2
trim_trailing_whitespace = true
insert_final_newline = true

EditorConfig 仅可能简略的配置一些规定，并不能齐全满足需要，只是起到一个 跨编辑器和 IDE 对立编码格调的兜底配置，如果要达到很好的代码标准和编码格调的对立，还须要配置其余代码检查和格式化工具应用，比方：ESLint 和 Prettier。

ESLint 是一款插件化的 JavaScript 代码动态查看工具，其外围是通过 Espree（默认解析器）对 JavaScript 代码解析失去的 AST（形象语法树）进行模式匹配（每条规定都会对匹配的过程进行监听，每当匹配到一个类型，相应的规定就会进行查看），剖析代码达到查看代码品质和编码格调的能力，同时有些 lint 规定能够防止 bug 的产生，在进步代码可读性、可维护性的前提下，缩小问题数量。

代码查看是一种动态的剖析，罕用于寻找有问题的模式或者代码，并且不依赖于具体的编码格调。对大多数编程语言来说都会有代码查看，一般来说编译程序会内置查看工具。

ESLint 可能获得成功的几个起因：

能够用其余的 parser 来代替默认的 parser，只有它的输入与 Esprima(或 Espree)兼容；
可扩展性是要害
规定设置为齐全可配置，意味着能够敞开每一个规定而只运行根底语法验证，或把 ESLint 默认绑定的规定和你的自定义规定混合

初始化 ESLint

npm install eslint -D

npx eslint --init

在 eslint 初始化的时候会询问如何配置，具体问题及选项能够参考：https://github.com/eslint/esl…。

eslint 初始化后会在文件夹的根目录生成一个 .eslintrc.js 文件。

运行 npx eslint . 能够校验文件夹下的所有文件。

运行 npx eslint . --fix 能够修复文件中的问题

应用 ESLint 命令行的形式是被动进行的编译动作，这个动作注定不是高频的，然而谁也不想写了几百行代码后，运行 ESLint 校验发现有 n 个正告和报错，所以在编码的过程中实时看到校验后果是很有必要的。

在 VS Code 中能够装置 ESLint 插件，就能够让编辑器实时的提醒正告和报错，不用再等到编译时提醒了。

当然也能够为 ESLint 启用“保留时主动修复”：

"editor.codeActionsOnSave": {"source.fixAll.eslint": true}

VS Code 插件运行须要本地我的项目的 ESLint 相干插件和配置都存在（依赖、配置文件），但不肯定要被编译。

既然在 VS Code 中用上了 ESLint 插件能实时提醒正告和报错了，那么是不是就用不到命令行的 ESLint 了?

答案是还须要命令行的 ESLint，因为不能保障我的项目的所有开发者都用了 VS Code，或者也有可能把 ESLint 插件手动关掉了，不管怎样，提交到仓库中的代码必须合乎对立的代码标准和编码格调，所以在提交到仓库之前必须要进行一次 ESLint 校验。

ESLint 的配置文件命名能够是 eslintrc.js、eslintrc.yaml、eslintrc.json，甚至配置在 package.json 中的 eslintConfig 属性。不过 .eslintrc 这个配置文件命名据说要被废除。

从源码中能够看出配置文件的优先级如下：

const configFilenames = [
     .eslintrc.js ,
     .eslintrc.cjs ,
     .eslintrc.yaml ,
     .eslintrc.yml ,
     .eslintrc.json ,
     .eslintrc ,
     package.json
];

以下是较为全面的配置项解析：

ESLint 配置项解析
ESLint 之解析包名
ESLint 配置文件.eslintrc 参数阐明

简略说一下三种解析器：

espree：ESLint 默认解析器
@babel/eslint-parser：能够查看所有无效的 babel 代码，即让 ES6+ 的代码和那些试验性质的语法也能用 ESLint
@typescript-eslint/parser：该解析器将 TypeScript 转换成与 espree 兼容的格局，从而容许 ESLint 验证 TypeScript 源代码。

额定说一下，ESLint 默认解析器到底是 Esprima 还是 Espree？ESLint 最早的版本默认解析器是应用的开源的 Esprima，不过当 ESLint 打算反对 ES6 和 JSX 时发现 Esprima 保护频率不高并且还没有打算公布对 ES6 的反对，通过多方调研，最初抉择实现本人的解析器就是 Espree，当初的 ESLint 默认解析器是 Espree。

扩大能够共享配置，并且能够批改规定，而后笼罩掉某些不须要的配置。

简略说一下几种常见的扩大：

eslint-config-airbnb：提供了所有的 Airbnb 的 ESLint 配置。该配置蕴含了 React 相干的 ESLint 规定，所以须要装置 eslint-plugin-import, eslint-plugin-react, eslint-plugin-react-hooks, eslint-plugin-jsx-a11y 这四个插件，并且它不反对 React Hooks rules，如果要反对还须要启用 eslint-config-airbnb/hooks 这个扩大。
eslint-config-airbnb-base：不蕴含 React 的规定，个别用于服务端查看
eslint-config-prettier：禁用掉所有那些非必须或者和 prettier 抵触的 ESLint 规定，这样能够防止其余共享配置影响到 Prettier 的格式化。留神该扩大只是将波及到的规定关掉了（off），所以它只有在和别的配置一起应用的时候才有意义。例如 extends: ["eslint:recommended", "prettier"]，prettier 写在最初，前面的规定会笼罩后面的。

简略说一下几种常见的插件：

@babel/eslint-plugin：@babel/eslint-parser 解析器搭档的插件，为了反对 ES6+ 的代码，@babel/eslint-plugin 从新实现了有问题的规定，防止谬误误报。
eslint-plugin-import：这个插件的目标是反对查看 ES6+ 的 import/export 语法，也能防止文件门路和导入名称的拼写错误
eslint-plugin-jsx-a11y：查看 JSX 元素的可拜访性
eslint-plugin-react：
React 专用的校验规定插件
@typescript-eslint/eslint-plugin：提供 TypeScript 代码的查看规定
eslint-plugin-prettier：让 ESLint 和 Prettier 有良好的配合，这个插件的次要作用是将 prettier 作为 ESLint 的规定来应用，相当于代码不合乎 Prettier 的规范时，会报一个 ESLint 谬误，同时也能够通过 eslint --fix 来进行格式化。相当于把 Prettier 整合进了 ESLint 中。

重点说一下 ESLint 的 rules。官网举荐的规定能够应用 "extends": ["eslint:recommended"] 来开启举荐规定，点击查看具体文档。

ESLint 的规定提醒等级：

off 或 0：敞开规定
warn 或 1：开启规定，warn 级别的谬误只是正告，不会导致程序退出
error 或 2：开启规定，error 级别的谬误当被触发时，程序会推出

ESlint 的规定自身又能够分为两类：

规定没有属性，只需管制是开启还是敞开，例如："eqeqeq": "off" 敞开全等校验
规定有本人的属性，例如："quotes": ["error", "double"]

还有一点很重要，咱们能够通过 rules 这个配置项配置任何想要的规定，它会笼罩 extends 和 plugins 中引入的配置项，也就是说 .eslintrc.* 中 rules 配置的规定优先级很高。

有时候咱们须要应用自定义规定，自定义 ESLint 规定的实现次要在于了解一个 rule 的构造：

例如：no-with

module.exports = {
  // 蕴含规定的元数据, 包含规定的类型，文档，是否举荐规定，是否可修复等信息
  meta: {
    // 批示规定的类型，值为 "problem"、"suggestion" 或 "layout"
    type: 'suggestion',
    docs: {
      // 对 ESLint 外围规定来说是必须的
      description: 'disallow `with` statements', // 提供规定的简短形容在规定首页展现
      // category (string) 指定规定在规定首页处于的分类
      recommended: true, // 配置文件中的 "extends": "eslint:recommended" 属性是否启用该规定
      url: 'https://eslint.org/docs/rules/no-with', // 指定能够拜访残缺文档的 url
    },

    // fixable 如果没有 fixable 属性，即便规定实现了 fix 性能，ESLint 也不会进行修复。如果规定不是可修复的，就省略 fixable 属性。schema: [], // 指定该选项 这样的 ESLint 能够防止有效的规定配置
    // deprecated (boolean) 表明规定是已被弃用。如果规定尚未被弃用，你能够省略 deprecated 属性。messages: {unexpectedWith: "Unexpected use of'with'statement.",},
  },

  // create (function) 返回一个对象，其中蕴含了 ESLint 在遍历 js 代码的形象语法树 AST (ESTree 定义的 AST) 时，用来拜访节点的办法。入参为该节点。create(context) {
    // 如果一个 key 是个节点类型或 selector，在 向下 遍历树时，ESLint 调用 visitor 函数
    // 如果一个 key 是个节点类型或 selector，并带有 :exit，在 向上 遍历树时，ESLint 调用 visitor 函数
    // 如果一个 key 是个事件名字，ESLint 为代码路径分析调用 handler 函数
    // selector 类型能够到 estree 查找
    return {
      // 入参为节点 node
      WithStatement(node) {context.report({ node, messageId: 'unexpectedWith'})
      },
    }
  },
}

开发一个自定义规定，能够查看官网文档：https://eslint.org/docs/lates…。

有几个开发插件或介绍 ESLint 原理的文章能够看一下：

自定义 ESLint 规定，让代码继续漂亮
浅析 ESLint 原理

overrides：咱们在 .eslintrc.* 的 rules 中配置的规定个别都是全局失效，通过 overrides 能够针对一些文件笼罩一些规定。
settings：通过 settings 能够像每条 rule 传入一些自定义的配置内容。

先查看有没有内联配置，如果是命令行在查看有没有配置参数
在要检测的文件同一目录里寻找 .eslintrc.* 和 package.json
紧接着在父级目录寻找，始终找到文件系统的根目录
如果在前两步发现有 root: true 的配置，进行在付目录中寻找 .eslintrc.*
如果以上步骤都没找到，则回退到用户主目录 ~/.eslintrc 中定义的默认配置

`.eslintignore` 文件

能够通过在我的项目根目录创立一个 .eslintignore 文件通知 ESLint 去疏忽特定的文件和目录。.eslintignore 文件是一个纯文本文件，其中的每一行都是一个 glob 模式表明哪些门路应该疏忽检测，相似于.gitignore。

例如：

# 这是一个正文
node_modules/
dist/*.js

ESLint 疏忽文件还能够再命令行中通过参数从新设置：eslint . --ignore-path .gitignore，即间接应用 .gitignore 当做 .eslintignore

Prettier 官网介绍是这样说的，Prettier 是一个有主意的代码格式化工具，反对多种语言并且集成到了很多编辑器中，并且曾经成为了解决所有代码格局问题的优先计划了。

在格式化代码方面，Prettier 和 ESLint 的确有一些重叠，然而从大局观看两者的侧重点不同：ESLint 次要工作是查看代码品质并给出提醒 ，它所能提供的格式化性能很无限（ESLint 也不举荐应用本人的格式化性能），并且只反对 JavaScript/TypeScript； 而 Prettier 在格式化代码方面具备更大劣势，反对 JavaScript、Flow、TypeScript、CSS、SCSS、Less、JSX、Vue、GraphQL、JSON、Markdown 等语言。

npm install prettier -D

# 格式化所有文件
npx prettier --write .

当咱们提交代码时，应用命令行校验代码格局，再回去逐行改变格局，从新提交代码是非常影响效率的行为，另外如果我的项目过大，改变的文件很多，应用 Prettier 进行格式化的工夫可能也会较长。

VS Code 装置了 Prettier 插件，这样在保留文件时就能格式化文件从而实现即时格式化。

装置完 Prettier 插件后，在用户或者工作区设置（即 settings.json）中将 VS Code 的默认格式化程序设置为 Prettier。

例如：

{
  // 设置全副语言在保留时主动格式化
  "editor.formatOnSave": true,
  // 设置全副语言的默认格式化程序为 prettier
  "editor.defaultFormatter": "esbenp.prettier-vscode",
  // 设置特定语言 JavaScript 的默认格式化程序为 prettier，并设置在保留时主动格式化
  "": {"editor.formatOnSave": true,"editor.defaultFormatter":"esbenp.prettier-vscode"},
  // prettier 插件配置的公共规定
  "prettier.semi": true,
  "prettier.arrowParens": "avoid",
  "prettier.singleQuote": false,
  "prettier.tabWidth": 2,
  // vue 文件应用 vetur 作为默认格式化工具
  "[vue]": {
    "editor.defaultFormatter": "octref.vetur",
    "editor.formatOnSave": true
  },
  // vetur 把格式化 JavaScript 文件交给 prettier 解决
  "vetur.format.defaultFormatter.js": "prettier",
  "vetur.format.defaultFormatterOptions": {
    // vetur 应用的 prettier 的规定，此处的规定比下面设置的公共规定优先级高
    "prettier": {
      "semi": false,
      "singleQuote": true
    }
  }
}

对于特定语言默认有：javascript、javascriptreact、typescript、typescriptreact、json、graphql。其余的语言能够在 settings.json 中应用 files.associations 关联文件格式。

还是跟 ESLint 一样的问题，既然在 VS Code 中用上了 Prettier 插件能即时进行格式化了，那么是不是就用不到命令行的 Prettier？

答案是还须要命令行的 Prettier，因为不能保障我的项目的所有开发者都用了 VS Code，或者也有可能把 Prettier 插件手动关掉了，不管怎样，提交到仓库中的代码必须合乎对立的代码标准和编码格调，所以在提交到仓库之前必须要进行一次 Prettier 格式化。

Prettier 配置文件反对多种形式：

根目录创立 .prettierrc 文件，可能写入 YML、JSON 的配置格局，并且反对 .yaml、.yml、.json、.js；
根目录创立 prettier.config.js 文件，并对外 export 一个对象
在 package.json 中新建 Prettier 属性

例如创立 prettierrc.js：

module.exports = {
  printWidth: 80, // 换行的宽度，如果超过会进行换行，默认为 80
  tabWidth: 2, //tab 的空格宽度，默认为 80
  useTabs: false, // 缩进用 tab 还是空格，默认为 false，示意用空格进行缩减
  singleQuote: false, // 字符串是否应用单引号，JSX 会疏忽这个配置，默认为 false，应用双引号
  semi: true, // 行尾是否应用分号，默认为 true
  trailingComma: 'none', // 是否应用尾逗号，有三个可选值 "<none|es5|all>"
  bracketSpacing: true, // 对象大括号间接是否有空格，默认为 true，成果：{foo: bar}
  arrowParens: 'avoid', // 箭头函数的单参数是否用括号包裹，有两个可选值 "<always|avoid>"
  parser: 'babylon', // 代码的解析引擎，默认为 babylon，与 babel 雷同。}

`.prettierignore` 文件

应用 .prettierignore 文件齐全疏忽（即不从新格式化）某些文件和文件夹，跟 .eslintignore 文件一样。

ESLint 和 Prettier 搭配应用时，他们有交加的那局部规定可能会导致 ESLint 和 Prettier 格式化后的代码格局不统一（比方单双引号 / 是否应用分号等）。例如 Prettier 格式化代码后再用 ESLint 去检测，会呈现一些因为格式化导致的正告或报错，ESLint 进行修复后，又不合乎 Prettier 的格局，而后保留的时候又会被格式化，而后陷入“死循环”。

这种问题的次要解决思路是在 ESLint 的规定配置文件上做文章，装置特定的扩大，把其配置到规定的尾部，实现 Prettier 规定对 ESLint 规定的笼罩。

这就须要之前说的 eslint-config-prettier 扩大，它的作用就是禁用掉所有那些非必须或者和 prettier 抵触的 ESLint 规定。

npm install eslint-config-prettier -D

// 在 .eslintrc.* 文件中的 extends 字段的最初增加 prettier
{
  "extends": [
    "eslint:recommended", // 曾经配置的扩大
    "prettier" // prettier 扩大增加到其余扩大的前面，能够实现 Prettier 规定对 ESLint 规定的笼罩
  ]
}

以上只是把 ESLint 和 Prettier 会产生的一些抵触解决掉了，实现了运行 ESLint 命令会依照 Prettier 的规定做相干校验。然而如果要实现代码格式化，还得须要手动运行 Prettier 的相干命令来进行格式化，社区的解决方案是在应用 eslint --fix 的时候，理论应用 Prettier 来代替 ESLint 的格式化性能。

这时候就须要用到之前讲过的 eslint-plugin-prettier

npm install eslint-plugin-prettier -D

// 在 .eslintrc.* 中的配置如下
{"plugins": ["prettier"],
  "rules": {"prettier/prettier": "error"}
}

此时再执行 eslint --fix 理论应用的是 Prettier 的规定去格式化代码。在 rules 中增加 "prettier/prettier": "error"，当代码呈现 Prettier 的规定校验出的格式化问题，ESLint 会报错。

如果想同时解决规定抵触和主动格式化，能够通过如下形式简化：

// 在 .eslintrc.* 中的配置如下
{"extends": ["plugin:prettier/recommended"]
}

下面的配置等价与上面的配置：

{"extends": ["prettier"], // eslint-config-prettier 提供的，用于笼罩起抵触的规定
  "plugins": ["prettier"], // 注册 eslint-plugin-prettier 插件
  "rules": {
    "prettier/prettier": "error",
    "arrow-body-style": "off",
    "prefer-arrow-callback": "off"
  }
}

在整个前端代码标准和编程格调的流程最初两个工具，简略介绍一下。

为了保障仓库中的代码是合乎代码标准和编程格调的，最好的办法是确保本地的代码曾经通过查看能力 push 到近程，即在本地进行 git commit 操作前触发对代码的查看，所以就须要 githook 工具 husky。

# husky 的初始化，创立 .husky/ 目录并制订该目录为 git hooks 所在的目录，并且在 .husky/ 目录下会新增 pre-commit 的 shell 脚本，并且退出了 npm test 命令

npx husky-init && npm install

# 在进行 git commit 之前运行 npx eslint src/** 查看

npx husky add .husky/pre-commit "npx eslint src/**"

不过每次提交都查看所有的文件效率非常低，最好是每次只对以后批改后的文件进行扫描，即只对 git add 退出到 stage 缓存区的文件进行扫描，从而实现只对增量代码进行查看。这里就须要应用 lint-staged 工具来辨认被退出到 stage 缓存区的文件。

// package.json
{
  "lint-staged": {"*.{js}": ["npx eslint --fix"]
  }
}

对以后改变的 .js 文件在提交时进行检测和主动修复，主动修复实现后 lint-staged 默认会把改变的文件再次 add 到暂存区，如果有无奈修复的谬误会报错提醒。

搭配 husky 应用时，批改 .husky/pre-commit，在 commit 之前运行 npx lint-staged 来校验提交到暂存区中的文件：

#!/bin/sh

. "$(dirname"$0")/_/husky.sh"

npx lint-staged

应用 mrm

# mrm 最新版本应用 npx 执行有问题，所以应用 2.x 版本
npx mrm@2 lint-staged

它其实相当于一个工作，做了三件事：

在 package.json 中减少了 lint-staged 的配置
设置 pre-commit git hook
装置依赖

缩进的代码格调到底是 2 个空格还是 4 个空格是受谁管制的？VS Code 默认设置？还是 Prettier?

1、.vscode/settings.json 中的 "editor.tabSize": 4，不过如果设置 "editor.detectIndentation": true , 就会依据关上文件的内容自动检测，例如尽管设置的 tabSize 为 4，然而以后文件关上时文件内容的 tabSize 为 2，所以仍然会沿用 2，如果设置为 false，后续的 tabSize 则会应用 4

{
      // 依据关上文件的内容自动检测 #editor.tabSize# 和 #editor.intertSpaces#
      // 例如尽管上面设置的 tabSize 为 4，然而以后文件关上时是文件内容的 tabSize 为 2，所以仍然会沿用 2，如果设置为 false，后续的 tabSize 则会应用 4
      "editor.detectIndentation": true,
      "editor.insertSpaces": true, // 是否应用空格
      "editor.tabSize": 4 // 空格或者制表符的大小
}

到当初为止，新建一个 index.js 文件缩进是 4 个空格

2、VS Code 中装置了 EditorConfig 插件，并且创立了 .editorconfig 配置文件，缩进的代码格调就会由 EditorConfig 的 indent_style 和 indent_size 管制。

[*.{js,jsx,ts,tsx,vue}]

indent_style = space
indent_size = 2

到当初为止，index.js 文件的缩进是 2 个空格

3、VS Code 装置 Prettier 插件，并且创立了 .prettierrc.js 配置文件，缩进的代码格调就会由 Prettier 的 tabWdith管制。

tabWidth: 6

到当初为止，index.js 文件的缩进是 6 个空格

所以，缩进的代码格调是须要具体看装置什么插件，总起来说如果三种配置和工具都用上了，优先级：Prettier > EditorConfig > VS Code settings.json

Visual Studio Code 应用笔记
你不晓得的 Vscode 之我的项目束缚 | 仓库配置
对立代码格调工具——EditorConfig
回顾 ESLint 的胜利
ESLint 配置项解析
ESLint 之解析包名
ESLint 工作原理探讨
Eslint 的实现原理，其实挺简略
ESLint 工作原理探讨
零根底了解 ESLint 外围原理
浅析 eslint 原理
本人入手写合乎本人业务需要的 eslint 规定
为什么 Eslint 能够检查和修复格局问题，而 Babel 不能够？
从 ESLint 开启我的项目格式化
前端代码标准工程化最佳实际 – ESLint
Prettier 看这一篇就行了

笔者在某教育公司的第 5 波裁员中拿到 N+1，当初筹备求职中，如果贵司有前端相干职位正在招聘，烦请分割笔者，请注明来意哈，感激浏览。

wx: qiqihaobenben
emial: chenfangxu_qixin@163.com
github: https://github.com/qiqihaobenben

关于前端:VSCode-中前端代码规范和编码风格实践详解

VS Code 编辑器本身配置

VS Code 的 `.vscode` 文件夹

`settings.json`

罕用配置

屏蔽文件

其余配置

`extensions.json`

对于工作相干 `tasks.json` 和调试相干的 `launch.json`，后续有机会再聊。

EditorConfig

配置 `.editorconfig`

应用的根底库和内置对象实例

ESLint

ESLint 命令行

VS Code 应用 ESLint 插件

ESLint 配置项解析

解析器（parse）

扩大（extends）

插件（plugins）

规定（rules）

几个不常见的配置

ESLint 检测配置文件步骤

`.eslintignore` 文件

Prettier

Prettier 命令行

VS Code 应用 Prettier 插件

Prettier 配置

配置文件

属性

`.prettierignore` 文件

Prettier 与 ESLint 配合

Husky + lint-staged

husky + lint-staged + eslint 更简略的集成形式

答复文章开篇的问题

举荐浏览

VS Code 编辑器本身配置

VS Code 的 .vscode 文件夹

settings.json

罕用配置

屏蔽文件

其余配置

extensions.json

对于 工作相干 tasks.json 和 调试相干的 launch.json，后续有机会再聊。

EditorConfig

配置 .editorconfig

应用的根底库和内置对象实例

ESLint

ESLint 命令行

VS Code 应用 ESLint 插件

ESLint 配置项解析

解析器（parse）

扩大（extends）

插件（plugins）

规定（rules）

几个不常见的配置

ESLint 检测配置文件步骤

.eslintignore 文件

Prettier

Prettier 命令行

VS Code 应用 Prettier 插件

Prettier 配置

配置文件

属性

.prettierignore 文件

Prettier 与 ESLint 配合

Husky + lint-staged

husky + lint-staged + eslint 更简略的集成形式

答复文章开篇的问题

举荐浏览

VS Code 的 `.vscode` 文件夹

`settings.json`

`extensions.json`

对于工作相干 `tasks.json` 和调试相干的 `launch.json`，后续有机会再聊。

配置 `.editorconfig`

`.eslintignore` 文件

`.prettierignore` 文件