Ⅰ 请教如何在phpStorm中配置eslint
使用ESlint
一、ESLint跟jsLint和JSHint类似，但有以下区别：
1.使用Espree进行js解析(parse)
2.用AST抽象语法树去识别(evaluate)代码中的模式3.每个规则都是独立的插件
二、安装
全局安装：
npm install -g eslint
三、使用
如果是第一次使用，eslint --init 命令帮你完成初始化，生成.eslintrc文件然后eslint test.js test2.js
四、配置
{
"rules": {
"semi": ["error", "always"],
"quotes": ["error", "double"]
}
}
提示有三个level：
"off" or 0 - 关闭这个规则校验
"warn" or 1 - 开启这个规则校验，但只是提醒，不会退出"error" or 2 - 开启这个规则校验，并退出
五、常见问题
1.为什么不用jslint
创建eslint是因为急需插件化的校验工具
2.ESLint跟JSHint、JSCS的比较
ESLint比JSlint要慢2~3倍，因为ESLint在识别代码前需要用Espress构建AST,而JSHint在解析的时候就会识别代码。虽然慢些，但不至于成为痛点。
ESLint比JSCS快，（as ESLint uses a single-pass traversal for analysis whereas JSCS using a querying model.）3.ESLint仅仅是校验还是也检查代码风格
都有。ESLint does both traditional linting (looking for problematic patterns) and style checking (enforcement of conventions). You can use it for both.
4.支持es6吗？
支持。参考配置eslint.org/docs/user-guide/configuring5.支持JSX？
支持，但并不表示支持React。（Yes, ESLint natively supports parsing JSX syntax (this must be enabled in configuration.). Please note that supporting JSX syntax is not the same as supporting React. React applies specific semantics to JSX syntax that ESLint doesn't recognize. We recommend using eslint-plugin-react if you are using React and want React semantics.）5.支持es7吗？
本身不支持，可以使用babel-eslint
六、下面详细介绍下配置，地址eslint.org/docs/user-guide/configuring1.配置ESLint
主要有两种方法配置
（1）配置注释，直接嵌入到js文件中
（2）配置文件，使用js、json或者yaml文件来为整个目录及其子目录配置。形式有：.eslintrc.*文件，或者在package.json中配置eslintConfig字段，或者在命令行里配置。
配置分几个方面：
（1）环境（env）：设置你的脚本的目标运行环境，如browser，amd，es6，commonjs等，每种环境有预设的全局变量（2）全局变量：增加的全局变量供运行时使用（3）规则（rules）：设定的规则及该规则对应的报错level2.配置解析器选项（Specifying Parser Options）默认仅支持ES5语法，可以设置为es6 es7 jsx等。
复制代码
{
"parserOptions": {
"ecmaVersion": 6, // 可选 3 5（默认） 6 7"sourceType": "mole", // 可选script（默认） mole"ecmaFeatures": {
"jsx": true
},
},
"rules": {
"semi": 2
}
}
复制代码
3.配置解析器（Specifying Parser），需要本地npm模块{
"parser": "esprima", // Espree(默认) Esprima Babel-ESLint"rules": { "semi": "error" } }
4.配置环境（Specifying Environments），可以多选复制代码
browser - browser global variables.
node - Node.js global variables and Node.js scoping.
commonjs - CommonJS global variables and CommonJS scoping (use this for browser-only code that uses Browserify/WebPack).
shared-node-browser - Globals common to both Node and Browser.
es6 - enable all ECMAScript 6 features except for moles.
worker - web workers global variables.
amd - defines require() and define() as global variables as per the amd spec.
mocha - adds all of the Mocha testing global variables.
jasmine - adds all of the Jasmine testing global variables for version 1.3 and 2.0.
jest - Jest global variables.
phantomjs - PhantomJS global variables.
protractor - Protractor global variables.
qunit - QUnit global variables.
jquery - jQuery global variables.
prototypejs - Prototype.js global variables.
shelljs - ShellJS global variables.
meteor - Meteor global variables.
mongo - MongoDB global variables.
applescript - AppleScript global variables.
nashorn - Java 8 Nashorn global variables.
serviceworker - Service Worker global variables.
atomtest - Atom test helper globals.
embertest - Ember test helper globals.
webextensions - WebExtensions globals.
greasemonkey - GreaseMonkey globals.
复制代码
如果要在待校验文件里面配置可以这样配置：
/*eslint-env node, mocha */
如果要在配置文件中配置：
{
"env": {
"browser": true,
"node": true
}
}
如果在package.json中配置：
复制代码
{
"name": "mypackage",
"version": "0.0.1",
"eslintConfig": {
"env": {
"browser": true,
"node": true
}
}
}
复制代码
如果在YAML中配置：
---
env:
browser: true
node: true
也可以用插件
{
"plugins": ["example"],
"env": {
"example/custom": true
}
}
5.配置全局变量（Specifying Globals）
定义了全局变量以后，使用他们，ESLint不会发出警告。
在js文件中定义：
/*global var1, var2*/
设置read only
/*global var1:false, var2:false*/
在配置文件中：
{
"globals": {
"var1": true,
"var2": false
}
}
6.配置插件（Configuring Plugins）
使用npm安装第三方插件
{
"plugins": [
"plugin1",
"eslint-plugin-plugin2"
]
}
7.配置规则（Configuring Rules）
js中配置：
/*eslint eqeqeq: "off", curly: "error"*/
或者：
/*eslint eqeqeq: 0, curly: 2*/
如果规则有多个选项：
/*eslint quotes: ["error", "double"], curly: 2*/在配置文件中设置：
复制代码
{
"rules": {
"eqeqeq": "off",
"curly": "error",
"quotes": ["error", "double"]
}
}
复制代码
使用插件：
复制代码
{
"plugins": [
"plugin1"
],
"rules": {
"eqeqeq": "off",
"curly": "error",
"quotes": ["error", "double"],
"plugin1/rule1": "error"
}
}
复制代码
/*eslint "plugin1/rule1": "error" */
临时关闭eslint校验：
/*eslint-disable */
//Disable all rules between comments
alert('foo');
/*eslint-enable */
/*eslint-disable no-alert, no-console */
alert('foo');
console.log('bar');
/*eslint-enable no-alert */
在js特定行关闭校验：
alert('foo'); // eslint-disable-line
// eslint-disable-next-line
alert('foo');
alert('foo'); // eslint-disable-line no-alert, quotes, semi// eslint-disable-next-line no-alert, quotes, semialert('foo');
8.增加共享设置（Adding Shared Settings）
{
"settings": {
"sharedData": "Hello"
}
}
9.使用配置文件
eslint -c myconfig.json myfiletotest.js
10.继承配置文件（Extending Configuration Files）复制代码
{
"extends": [
"./node_moles/coding-standard/eslintDefaults.js",// Override eslintDefaults.js
"./node_moles/coding-standard/.eslintrc-es6",// Override .eslintrc-es6
"./node_moles/coding-standard/.eslintrc-jsx",],
"rules": {
// Override any settings from the "parent" configuration"eqeqeq": "warn"
}
}
复制代码
11.忽略文件或目录(Ignoring Files and Directories)建立.eslintignore文件
复制代码
# /node_moles and /bower_components ignored by default# Ignore files compiled from TypeScript and CoffeeScript**/*.{ts,coffee}.js
# Ignore built files except build/index.jsbuild/
!build/index.js
Ⅱ ESLint配置详解(一) - 超级深入详细
如果项目目录下有多个配置文件，ESLint 只会使用一个，优先级为： .eslintrc.js > .eslintrc > package.json ，一般我们都是在 .eslintrc.js 配置。
同时，如果配置文件里没有 "root": true 这个属性，ESLint就会继续向外寻找配置文件，直到找到有 "root": true 的为止，所有这些配置文件的规则都会被层叠应用。若有重复的属性配置，则离文件更近的配置文件具有更高的优先级。
当想要所有项目都遵循一个特定的约定时会很有用，但还是建议给项目根目录的 .eslintrc.js 加上 root: true
1.1 extends - Extending Configuration Files
一个ESLint配置文件，一旦扩展了(即从外部引入了其他配置包)，就能继承另一个配置文件的所有属性(包括rules, plugins, and language option在内)，然后通过merge合并/覆盖所有原本的配置。
extends 属性的值可以是：
"eslint:recommended" 这个扩展包帮我们启用了一系列核心规则，这些规则是在 rules页面 中被标记为 ✅ 的常见问题。
ESLint插件 是可以给ESLint添加很多扩展规则的npm包，它可以执行很多方法，包括但不限于 添加新规则 和 导出 可共享配置 。
在添加到配置文件 (如 .eslintrc.js ) 的 plugins 的 时候，可以省略插件包名的 eslint-plugin- 前缀
在 extends 中插件字符串值则可以是：
插件包名的格式一般是 eslint-plugin-<plugin-name> ，就像 eslint-plugin-prettier ；
也可能是含命名空间包的格式 @<scope>/eslint-plugin-<plugin-name> ，例如 @vue/eslint-config-prettier；
甚至 @<scope>/eslint-plugin ，如 @jquery/eslint-plugin 。
通过extends设置的配置包加载的时候，是递归的形式去查找配置文件(最终是一个导出的对象，详细看 ② )，然后一步步派生继承的。
例如： extends: ["foo"] ，然后对应的 eslint-config-foo 有 plugins: ["bar"] , ESLint 会先找到 ./node_moles/ 下的 eslint-plugin-bar , (而不是 ./node_moles/eslint-config-foo/node_moles/)，更不会从祖先目录去查找。配置文件和基本配置中的每个插件都会唯一地解析。
按照上述规则，我们来梳理下 ["plugin:vue/essential", "eslint:recommended", "@vue/prettier"] (vue-cli4 + ESLint + prettier 的 默认extends值)的配置文件分别在哪里。仅帮助加深理解。
我们再去项目根目录的 ./node_moles 找 eslint-plugin-prettier 和 eslint-config-prettier 插件，然后得知，@vue/prettier最终导入了 ./node_moles/eslint-config-prettier/index.js 、 ./node_moles/eslint-config-prettier/vue.js 和 ./node_moles/eslint-plugin-prettier/eslint-plugin-prettier.js 的规则
parserOptions - Specifying Parser Options
指定你想要支持的 JavaScript 语言选项。默认支持 ECMAScript 5 语法。你可以覆盖该设置，以启用对 ECMAScript 其它版本和 JSX 的支持。
3.1 rules - Configuring Rules
ESLint 拥有大量的规则。你可以通过配置插件添加更多规则。使用注释或配置文件修改你项目中要使用的规则。要改变一个规则，你必须将规则 ID 设置为下列值之一：
3.1.1 在文件注释里配置规则 (只在当前文件生效)
上面的例子， eqeqeq 规则被关闭， curly 规则被打开，且定义为错误级别。出于便于理解的考虑，可以用字符串值，如果很熟悉的话用对应的数字来定义也是一样的。
如果一个规则有额外的参数选项，你可以用数组字面量语法来指定它们，比如：
这条注释为规则 quotes 指定了 “double”选项。数组的第一项总是规则的严重程度（数字/字符串）
3.1.2 在配置文件配置规则
要配置定义在插件中的一个规则，你必须使用 插件名/规则ID 的形式。比如：
规则 plugin1/rule1 表示来自插件 plugin1 的 rule1 规则。当指定来自插件的规则时，确保删除 eslint-plugin- 前缀。ESLint 在内部只使用没有前缀的名称去定位规则。
4.1 parser - Specifying Parser
被指定的解析器必须是可以从它的配置文件中加载的Node模块。这意味着应该使用 npm 单独安装这个解析器包；它必须符合 parser interface 。
4.2 plugins - Configuring Plugins
ESLint支持使用第三方插件。要使用插件，必须先用npm进行安装。
要在配置文件中配置插件，可以用 plugins 属性，它的值是包含插件名称的列表(数组)。其中，插件名可以省略 eslint-plugin- 前缀(如果有的话)。
插件是根据配置文件(如 eslintrc.js )解析的。换句话说，ESLint会像通过运行 require('eslint-plugin-pluginname') 一样加载我们配置在 eslintrc.js 中的插件。所以要保证在这个包在当前配置文件的./node_moles/下找得到。
连着 extends 属性讲比较清楚，因此其他已经在上面 1.1.2 - 插件具体是如何实现扩展配置的 讲过了。
避免文章冗长又碍可读性又分篇了，指路：➡️ ESLint配置详解(二) - 常用规则(Rules)集合
Ⅲ Taro (VUE style) 椤圭洰澧炲姞lint浠ュ強git hooks
鎺㈣ㄦ庝箞鍋氫箣鍓嶏紝鎴戜滑寰堟湁蹇呰佺粰 Lint 鏉ヤ釜娓呮櫚銆佸噯纭鐨勫畾涔夛紝wikipedia 鐨勫畾涔夊備笅锛
绠鍗曟潵璇达紝Lint 灏辨槸瀵逛唬鐮佸仛闈欐佸垎鏋愶紝骞惰瘯鍥炬壘鍑烘綔鍦ㄩ棶棰樼殑宸ュ叿锛屽疄鎴樹腑鎴戜滑涔熺敤 Lint 鏉ユ寚浣跨敤宸ュ叿鐨勮繃绋嬨
浣跨敤 Lint 浼氭湁浠涔堝ソ澶勫憿锛熷湪鎴戠湅鏉ヨ嚦灏戝叿鏈夊備笅 3 鐐癸細
鍙浠ユ涓嶅㈡皵鐨勮达紝濡傛灉浣犱笉鍋 Lint锛屽氨鏄鍦ㄦ氮璐硅嚜宸辩殑鏃堕棿锛屾氮璐瑰洟闃熺殑璧勬簮銆
閫氬父鏉ヨ村湪涓涓猇UE椤圭洰涓锛岄氳繃@vue/cli 鐢熸垚鐨勯」鐩锛屼細鑷鍔ㄥ畨瑁呮墍闇鐨刵pm 渚濊禆锛屽苟涓斿湪package.json 涓鐢熸垚鐩稿叧鐨別slint鍛戒护
浣嗗逛簬涓涓 Taro based VUE style 椤圭洰锛屾垜浠涔熷笇鏈涘湪寮鍙戝悓瀛︽彁浜や唬鐮 (git commit) 涔嬪墠灏辫繘琛屼唬鐮佽勮寖鐨勬娴嬶紝杩欐牱鍙浠ラ伩鍏嶅悗鏈熷啀涓嶆柇淇鏀逛唬鐮佸紓鍛充箣绫荤殑楹荤儲鍑虹幇銆
浣嗘槸@tarojs/cli 鐢熸垚椤圭洰鏃跺苟娌℃湁鍍廆vue/cli 鍒涘缓椤圭洰鏃惰嚜鍔ㄥ畨瑁呮墍闇鐨刵pm lib锛屼篃娌℃湁鍦╬ackage.json 涓鐢熸垚鐩稿簲鐨勫懡浠ゃ
閭ｄ箞鎴戜滑瑕佸備綍鍦╰aro 椤圭洰涓閰嶇疆eslint 浠ュ強git宸ヤ綔娴佺殑妫娴嬭Е鍙戝憿锛
棣栧厛鎴戜滑杩涜宔slint鏈韬鐨勯厤缃銆
闇瑕佸畨瑁呯殑npm 渚濊禆濡備笅锛
浠ヤ笂瑙勫垯鐨勫畨瑁咃紝涓鑸鎯呭喌涓嬪氨宸茬粡婊¤冻鎴戜滑瀵逛簬taro鐢熸垚鐨剉ue椤圭洰杩涜屼唬鐮佹娴嬩簡銆傛帴涓嬫潵濡傛灉鎴戜滑闇瑕佸筫slint瑙勫垯鐨勫簲鐢ㄨ繘琛岀壒娈婄殑閰嶇疆锛岃蜂慨鏀归」鐩鏍圭洰褰曚笅鐨.eslintrc.js 鏂囦欢銆
鐢变簬鎴戜滑闇瑕佸箆ue鏂囦欢杩涜屼唬鐮佽勫垯妫娴嬶紝鍥犳ら渶瑕佸湪 .eslintrc.js 鏂囦欢涓鏂板瀍xtends灞炴э細
鏇村氳︽儏璇峰弬瑙 https://eslint.org/docs/user-guide/configuring/
杩欓噷棣栧厛瑕佷粙缁嶄竴涓嬪挨澶у湪vue涓浣跨敤鐨剏orkie杩欎釜搴撱
鎵ц vue create 鍛戒护鐨勬椂鍊欙紝浼氬畨瑁呬竴涓鍖咃紝鍙锛歽orkie锛岃繖涓鍖呮槸灏ゅぇ fork 鑷 husky 鐨勶紝瀹冧咯鍔熻兘鏄涓鏍风殑锛岄兘鏄鐢熸垚涓浜 git hooks 鏂囦欢锛岃诲彇椤圭洰涓璸ackage.json鐨勭浉鍏抽厤缃椤瑰幓鎵ц屼竴浜涘懡浠わ紝鍖哄埆鏄灏ゅぇ鍋氫簡涓浜涢昏緫鍜岄厤缃涓婄殑鏀瑰姩銆
瀹夎呭畬杩欎釜鍖呬互鍚庯紝浼氳嚜鍔ㄦ墽琛 yorkie 鍖呴噷闈㈢殑涓涓鑴氭湰锛歜in/install.js
瀹夎呭畬鎴恲orkie杩欎釜鍖呬箣鍚庯紝浼氬湪浣犻」鐩涓嬬殑.git/hooks鐩褰曚腑鐢熸垚寰堝 git hooks 鏂囦欢锛
姝ゆ椂锛屽綋浣犳墽琛屼竴浜 git 鍛戒护鐨勬椂鍊欙紝姣斿傦細git push, git commit绛夛紝git 灏变細鎵ц岀浉搴旂殑 hook銆
杩欎箣鍚庯紝鎵ц実it commit杩欎釜鍛戒护鐨勬椂鍊欙紝git 浼氬幓鎵ц pre-commit 杩欎釜 hook銆
hook鎵ц岀殑鍐呭癸紝鍙浠ョ湅鍒板湪package.json 涓涓鑸宸茬粡杩涜屼簡閰嶇疆锛屾垜浠鐪嬩笅鍦╮ivendell椤圭洰涓鏄濡備綍杩涜岄厤缃鐨勶細
lint-staged
鐜板湪濡傛灉鎴戜滑鎵ц実it commit 鍛戒护鏃讹紝git hooks 浼氬幓鑷鍔ㄦ墽琛屽瑰簲鐨勫懡浠わ紝浣嗘ゆ椂浣犲彲鑳戒細寰楀埌涓涓閿欒鎻愮ず 锛堝傛灉鏄痸ue椤圭洰锛屽垯浣滀负渚濊禆宸茬粡瀹夎咃級锛屽憡璇変綘闇瑕佸畨瑁卨int-staged锛屾帴涓嬫潵鎴戜滑鐪嬬湅lint-staged 鏄鍋氫粈涔堢敤鐨勩
濡傛灉姣忔℃彁浜や唬鐮佷箣鍓嶏紝閮戒細鎵ц宔slint鍘绘娴嬫墍鏈夋枃浠堕噷鐨勪唬鐮佽勫垯闂棰橈紝濡傛灉浠ｇ爜涓瑙﹀彂浜嗚勫垯涓嶅厑璁哥殑浠ｇ爜椋庢牸锛屽氨浼氳緭鍑烘墍鏈夌殑闂棰橈細
鍙浠ョ湅鍒板傛灉椤圭洰杩樻湭杩涜岃繃浠ｇ爜椋庢牸妫娴嬶紝鍥犳や竴涓嬫娴嬪嚭鏉ヤ簡涓涓囧氫釜lint閿欒
鍗充究鏄缁忚繃浠ｇ爜瑙勮寖淇姝ｇ殑椤圭洰锛屾湁鏃跺欏叾浠栧悓瀛︾殑浠ｇ爜涓鍑虹幇浜唋int闂棰橈紝鍦ㄤ綘鎻愪氦浠ｇ爜鐨勬椂鍊欐姤浜嗗嚭鏉ワ紝瀵艰嚧浣犳病娉曟彁浜や唬鐮佷篃鏄涓浠跺緢鐑︿汉鐨勪簨鎯呫傚洜姝ゅ姞涓妉int-staged鐨勮兘鍔涳紝鍦ㄦ瘡涓浜烘湁鏂扮殑鎻愪氦鏃讹紝浠呭逛簬鏈変慨鏀圭殑浠ｇ爜杩涜屼唬鐮佹娴嬶紝灏辫В鍐充簡杩欐牱鐨勯棶棰樸
Feedly 鐨勫伐绋嬪笀 Andrey Okonetchnikov 寮鍙戠殑 lint-staged 灏辨槸鍩轰簬杩欎釜鎯虫硶锛屽叾涓 staged 鏄 Git 閲岄潰鐨勬傚康锛屾寚寰呮彁浜ゅ尯锛屼娇鐢 git commit -a锛屾垨鑰呭厛 git add 鐒跺悗 git commit 鐨勬椂鍊欙紝浣犵殑淇鏀逛唬鐮侀兘浼氱粡杩囧緟鎻愪氦鍖恒
lint-staged 鐢ㄦ硶濡備笅锛
棣栧厛锛屽畨瑁呬緷璧栵細
鐒跺悗锛屼慨鏀 package.json 閰嶇疆锛屽炲姞濡備笅鍏ュ彛锛
瀵逛簬鍒濇湡浠0鍒1鐨勯」鐩寮鍙戯紝鎴戜滑鍙鑳芥病鏈夌簿鍔涘幓娉ㄦ剰浠ｇ爜椋庢牸浠ュ強鑹濂界殑鏍煎紡銆備絾鏄涓嶅ソ鐨勪唬鐮侀庢牸鍙鑳介殣钘忕潃寰堝氫笉瀹规槗鍙戠幇鐨凚UG锛屽苟涓旂粰鍚庢潵鎺ユ墜淇鏀圭殑鍚屽﹀甫鏉ュ緢澶х殑楹荤儲銆
涓涓涓嶈勮寖鐨勪唬鐮佹枃浠讹紝璁╅槄璇昏呮懜涓嶇潃澶磋剳锛屼篃璁╀慨鏀圭殑浜鸿倽鍒板噷鏅ㄤ篃鎼炰笉娓呮氬叾涓鍗冧笣涓囩紩鐨勯昏緫鍏崇郴銆
鑰岃繖涓鎺ユ墜鐨勪汉鍙鑳藉氨鏄鍑犱釜鏈堜箣鍚庣殑浣犺嚜宸便
鎵浠ュ逛簬浠ｇ爜瑙勮寖鍜屾牸寮忕殑绮捐繘锛屼笉鏄鍦ㄦ氮璐规椂闂达紝鍙嶈屾槸涓轰簡鏈鏉ユ洿濂借妭鐪佷綘鐨勭敓鍛姐
save your life and save others' too
Ⅳ 现代配置指南——YAML 比 JSON 高级在哪
一直以来，前端工程中的配置大多都是 .js 文件或者 .json 文件，最常见的比如：
这些配置对前端非常友好，因为都是我们熟悉的 JS 对象结构。一般静态化的配置会选择 json 文件，而动态化的配置，涉及到引入其他模块，因此会选择 js 文件。
还有现在许多新工具同时支持多种配置，比如 Eslint ，两种格式的配置任你选择：
后来不知道什么时候，突然出现了一种以 .yaml 或 .yml 为后缀的配置文件。一开始以为是某个程序的专有配置，后来发现这个后缀的文件出现的频率越来越高，甚至 Eslint 也支持了第三种格式的配置 .eslintrc.yml 。
既然遇到了，那就去 探索 它！
下面我们从 YAML 的 出现背景 ， 使用场景 ， 具体用法 ， 高级操作 四个方面，看一下这个流行的现代化配置的神秘之处。
一个新工具的出现避免不了有两个原因：
YAML 这种新工具就属于后者。其实在 yaml 出现之前 js+json 用得也不错，也没什么特别难以处理的问题；但是 yaml 出现以后，开始觉得它好乱呀什么东西，后来了解它后，越用越喜欢，一个字就是优雅。
很多文章说选择 yaml 是因为 json 的各种问题，json 不适合做配置文件，这我觉得有些言过其实了。我更愿意将 yaml 看做是 json 的升级，因为 yaml 在格式简化和体验上表现确实不错，这个得承认。
下面我们对比 YAML 和 JSON，从两方面分析：
JSON 比较繁琐的地方是它严格的格式要求。比如这个对象：
在 JSON 中以下写法通通都是错的：
字符串的值必须 k->v 都是 "" 才行：
虽然是统一格式，但是使用上确实有不便利的地方。比如我在浏览器上测出了接口错误。然后把参数拷贝到 Postman 里调试，这时就我要手动给每个属性和值加 "" 号，非常繁琐。
YAML 则是另辟蹊径，直接把字符串符号干掉了。上面对象的同等 yaml 配置如下：
没错，就这么简单！
除了 "" 号，yaml 觉得 {} 和 [] 这种符号也是多余的，不如一起干掉。
于是呢，以这个对象数组为例：
转换成 yaml 是这样的：
对比一下这个精简程度，有什么理由不爱它？
说起增加的部分，最值得一提的，是 YAML 支持了 注释 。
用 JSON 写配置是不能有注释的，这就意味着我们的配置不会有备注，配置多了会非常凌乱，这是最不人性化的地方。
现在 yaml 支持了备注，以后配置可以是这样的：
把这种配置丢给新同事，还怕他看不懂配了啥吗？
除注释外，还支持配置复用的相关功能，这个后面说。
我接触的第一个 yaml 配置是 Flutter 项目的包管理文件 pubspec.yaml ，这个文件的作用和前端项目中的 package.json 一样，用于存放一些全局配置和应用依赖的包和版本。
看一下它的基本结构：
你看这个结构和 package.json 是不是基本一致？ dependencies 下列出应用依赖和版本， dev_dependencies 下的则是开发依赖。
后来在做 CI/CD 自动化部署的时候，我们用到了 GitHub Action。它需要多个 yaml 文件来定义不同的工作流，这个配置可比 flutter 复杂得多。
其实不光 GitHub Action，其他流行的类似的构建工具如 GitLab CI/CD，circleci，全部都是齐刷刷的 yaml 配置，因此如果你的项目要做 CI/CD 持续集成，不懂 yaml 语法肯定是不行的。
还有，接触过 Docker 的同学肯定知道 Docker Compose，它是 Docker 官方的单机编排工具，其配置文件 docker-compose.yml 也是妥妥的 yaml 格式。现在 Docker 正是如日中天的时候，使用 Docker 必然免不了编排，因此 yaml 语法早晚也要攻克。
上面说的这 3 个案例，几乎都是现代最新最流行的框架/工具。从它们身上可以看出来，yaml 必然是下一代配置文件的标准，并且是 前端-后端-运维 的通用标准。
说了这么多，你跃跃欲试了吗？下面我们详细介绍 yaml 语法。
介绍 yaml 语法会对比 json 解释，以便我们快速理解。
先看一下 yaml 的几个特点：
相比于 JSON 来说，最大的区别是用 缩进 来表示层级，这个和 Python 非常接近。还有强化的一点是支持了注释，JSON 默认是不支持的（虽然 TS 支持），这也对配置文件非常重要。
YAML 支持以下几种数据结构：
先看对象，上一个 json 例子：
转换成 yaml：
对象是最核心的结构，key 值的表示方法是 [key]: ，注意这里 冒号后面有个空格，一定不能少 。value 的值就是一个 纯量 ，且默认不需要引号。
数组和对象的结构差不多，区别是在 key 前用一个 - 符号标识这个是数组项。注意这里 也有一个空格 ，同样也不能少。
转换成 JSON 格式如下：
了解了基本的对象和数组，我们再来看一个复杂的结构。
众所周知，在实际项目配置中很少有简单的对象或数组，大多都是对象和数组相互嵌套而成。在 js 中我们称之为对象数组，而在 yaml 中我们叫 复合结构 。
比如这样一个稍复杂的 JSON：
转换成复合结构的 YAML：
若你想尝试更复杂结构的转换，可以在 这个 网页中在线实践。
纯量比较简单，对应的就是 js 的基本数据类型，支持如下：
比较特殊的两个，null 用 ~ 符号表示，时间大多用 2021-12-21 这种格式表示，如：
转换成 JS 后：
在 yaml 实战过程中，遇到过一些特殊场景，可能需要一些特殊的处理。
在 shell 中我们常见到一些参数很多，然后特别长的命令，如果命令都写在一行的话可读性会非常差。
假设下面的是一条长命令：
在 linux 中可以这样处理：
就是在每行后加 符号标识换行。然而在 YAML 中更简单，不需要加任何符号，直接换行即可：
YAML 默认会把换行符转换成 空格 ，因此转换后 JSON 如下，正是我们需要的：
然而有时候，我们的需求是 保留换行符 ，并不是把它转换成空格，又该怎么办呢？
这个也简单，只需要在首行加一个 | 符号：
转换成 JSON 变成了这样：
获取配置是指，在 YAML 文件中定义的某个配置，如何在代码（JS）里获取？
比如前端在 package.json 里有一个 version 的配置项表示应用版本，我们要在代码中获取版本，可以这么写：
JSON 是可以直接导入的，YAML 可就不行了，那怎么办呢？我们分环境解析：
在浏览器中
浏览器中代码用 webapck 打包，因此加一个 loader 即可：
然后配置 loader：
在组件中使用：
在 Node.js 中
Node.js 环境下没有 Webpack，因此读取 yaml 配置的方法也不一样。
首先安装一个 js-yaml 模块：
然后通过模块提供的方法获取：
配置项复用的意思是，对于定义过的配置，在后面的配置直接引用，而不是再写一遍，从而达到复用的目的。
YAML 中将定义的复用项称为锚点，用 & 标识；引用锚点则用 * 标识。
对应的 JSON 如下：
但是锚点有个弊端，就是不能作为 变量 在字符串中使用。比如：
此时 key2 的值就是普通字符串 _my name is *name_，引用变得无效了。
其实在实际开发中，字符串中使用变量还是很常见的。比如在复杂的命令中多次使用某个路径，这个时候这个路径就应该是一个变量，在多个命令中复用。
GitHub Action 中有这样的支持，定义一个环境变量，然后在其他的地方复用：
这种实现方式与 webpack 中使用环境变量类似，在构建的时候将变量替换成对应的字符串。
如果本文对你有启发，请甩手一个赞