一直以来,前端工程中的配置大多都是 .js
文件或者 .json
文件,最常见的比如:
- package.json
- babel.config.js
- webpack.config.js
这些配置对前端非常友好,因为都是我们熟悉的 JS 对象结构。一般静态化的配置会选择 json 文件,而动态化的配置,涉及到引入其他模块,因此会选择 js 文件。
还有现在许多新工具同时支持多种配置,比如 Eslint
,两种格式的配置任你选择:
- .eslintrc.json
- .eslintrc.js
后来不知道什么时候,突然出现了一种以 .yaml
或 .yml
为后缀的配置文件。一开始以为是某个程序的专有配置,后来发现这个后缀的文件出现的频率越来越高,甚至 Eslint 也支持了第三种格式的配置 .eslintrc.yml
。
既然遇到了,那就探索它!
下面我们从 YAML 的出现背景,使用场景,具体用法,高级操作四个方面,看一下这个流行的现代化配置的神秘之处。
出现背景
一个新工具的出现避免不了有两个原因:
- 旧工具在某些场景表现吃力,需要更优的替代方案
- 旧工具也没什么不好,只是新工具出现,比较而言显得它不太好
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 配置如下: