现代配置指南——YAML 比 JSON 高级在哪？

一直以来，前端工程中的配置大多都是 .js 文件或者 .json 文件，最常见的比如：

• package.json
• babel.config.js
• webpack.config.js

这些配置对前端非常友好，因为都是我们熟悉的 JS 对象结构。一般静态化的配置会选择 json 文件，而动态化的配置，涉及到引入其他模块，因此会选择 js 文件。

还有现在许多新工具同时支持多种配置，比如 Eslint，两种格式的配置任你选择：

• .eslintrc.json
• .eslintrc.js

后来不知道什么时候，突然出现了一种以 .yaml 或 .yml 为后缀的配置文件。一开始以为是某个程序的专有配置，后来发现这个后缀的文件出现的频率越来越高，甚至 Eslint 也支持了第三种格式的配置 .eslintrc.yml。

既然遇到了，那就探索它！

下面我们从 YAML 的出现背景，使用场景，具体用法，高级操作四个方面，看一下这个流行的现代化配置的神秘之处。

出现背景

一个新工具的出现避免不了有两个原因：

1. 旧工具在某些场景表现吃力，需要更优的替代方案
2. 旧工具也没什么不好，只是新工具出现，比较而言显得它不太好

YAML 这种新工具就属于后者。其实在 yaml 出现之前 js+json 用的也不错，也没什么特别难以处理的问题；但是 yaml 出现以后，开始觉得它好乱呀什么东西，后来了解它后，越用越喜欢，一个字就是优雅。

很多文章说选择 yaml 是因为 json 的各种问题，json 不适合做配置文件，这我觉得有些言过其实了。我更愿意将 yaml 看做是 json 的升级，因为 yaml 在格式简化和体验上表现确实不错，这个得承认。

下面我们对比 YAML 和 JSON，从两方面分析：

精简了什么？

JSON 比较繁琐的地方是它严格的格式要求。比如这个对象：

{
  name: 'ruims'
}

在 JSON 中以下写法通通都是错的：

// key 没引号不行
{
  name: 'ruims'
}
// key 不是 "" 号不行
{
  'name': 'ruims'
}
// value 不是 "" 号不行
{
  "name": 'ruims'
}

字符串的值必须 k->v 都是 "" 才行：

// 只能这样
{
  "name": "ruims"
}

虽然是统一格式，但是使用上确实有不便利的地方。比如我在浏览器上测出了接口错误。然后把参数拷贝到 Postman 里调试，这时就我要手动给每个属性和值加 "" 号，非常繁琐。

YAML 则是另辟蹊径，直接把字符串符号干掉了。上面对象的同等 yaml 配置如下：