大家肯定都发现了，现在越来越多的前端工具支持用JavaScript来进行自定义配置了。（比如说Babel或ESLint）不管大家之前出于什么原因选择JSON来写配置信息，从现在开始不要这么干了，改用JavaScript吧。

为什么呢？

一开始我犯了个错

前段时间，我为了模块化项目，把一些通用的代码抽象出来形成了单独的库，每个新的项目中都要把之前开发中配置的工具再配置一遍，Lint，Prettier等等。

一开始我想偷懒，每个新的项目都要配置一遍，那这些配置性的东西我想写的越少越好，所以我用了package.json中的JSON配置。然后我把所有的配置文件放在一个单独的包中，基于我们使用的工具（比如Babel）提供的扩展机制，我们可以共享配置。就像这样：

{
  "name": "nice-project",
  "version": "1.0.0",
  "babel": {
    "extends": "awesome-config",
    "plugins": ["lodash"]
  }
}

简单吧？但是！并不是每个工具都实现这种extends机制。

很巧的是，我还遇到了。发现缺少工具支持后，我在Github上寻找相关解决方案，肯定有大佬在我之前也遇到了这样的问题。果然还有很多小伙伴遇到了类似的问题。不过很快我也发现了，有的开发者没有考虑提供对所有可能的工具都提供扩展机制，因为已经存在一个天然的更好的选择了：使用JavaScript配置文件。

好吧，大佬就是大佬，我能怎么办呀，那我也只能用JavaScript来配置这些工具咯。当我用JavaScript重写了之前的JSON配置后，所有的问题都不是问题了，真香！

为什么要使用JavaScript配置

主要是因为JSON是一种数据格式，而JavaScript是编程语言。我们通过编程语言可以实现各种各样的计算与组合，不需要借助其它的工具就可以实现强大的配置功能。

而且，我们可以在JavaScript配置中写注释，甚至对它们做测试(虽然这看起来没多大意义)。

我们从几个方面展开来说说使用Javascript配置的好处：

轻松覆盖

我们如果require了一个JavaScript配置文件，我们可以轻松地修改返回的对象并重新导出它。

就像这样，我们的包里需要另外一个Babel插件时，像修改普通的对象一样修改它就好了。

const base = require("../babel.config.js");

module.exports = {
   ...base,
   plugins: [...base.plugins, "lodash"],
};

动态配置

我刚刚也说了，JSON是一种数据格式，缺乏动态性，我们喜欢用它来传数据，但是用来做配置其实不太行。如果使用JSON配置，哪怕有一丁点儿不同我们都要新建一个新的配置文件，如果换成JavaScript配置，我们可以通过一些编程技巧动态地返回需要的内容。

比如说我们只想在生产环境中使用某个插件，小菜一碟。

const base = require("../babel.config.js");

module.exports = {
  ...base,
  plugins: process.env.NODE_ENV === "production" 
    ? [...base.plugins, "lodash"]
    : base.plugins,
};

共享配置

进入前端世界后，一个比较爽的点是什么代码都可以通过npm发布，我们只需要创建一个恰当的package.json，然后npm publish就好了。

{
  "name": "my-babel-config",
  "version": "1.0.0",
  "description": "My babel config. ",
  "main": "babel.config.js",
  "files": ["babel.config.js"]
}

发布后，我们只需要在需要用到的项目中require即可：

const base = require("my-babel-config");

  module.exports = {
     ...base,
     plugins: [...base.plugins, "lodash"],
  };

注释

JSON不支持注释。有人说我们可以使用某些奇特的技巧实现这一需求，但是它们并它们不是JSON规范的一部分。JavaScript作为编程语言天然支持注释。我们可以将它们放在任意位置，ide还会给我们做好高亮。

module.exports = {
  "plugins": ["lodash"],
};

可测试

刚刚也提到了，我们可以测试Javascript配置文件，它们跟其它代码没有什么区别。有没有这个必要大家可以根据自己的场景判断，如果有需要，我们可以使用任何我们熟悉的测试框架来测试，比如Jest。

describe("config", () => {
  beforeEach(() => {
    oldEnv = process.env.NODE_ENV;
  });
  afterEach(() => {
    jest.resetModules();
    process.env.NODE_ENV = oldEnv;
  });

  it("uses lodash plugin in production", () => {
    process.env.NODE_ENV = "production";
    const config = require("./babel.config.js");
    expect(config.plugins.includes("lodash")).toBe(true);
  });

  it("does not use lodash plugin in other envs", () => {
    process.env.NODE_ENV = "production";
    const config = require("./babel.config.js");
    expect(config.plugins.includes("lodash")).toBe(false);
  });
});

总结

使用编程语言来配置工程可以轻松地实现很多JSON配置需要工具支持才能实现的功能，也让共享配置的门槛进一步降低，安卓很早就采用了Gradle来配置项目，就是看中了Gradle脚本使用groovy代码编写使得配置更加灵活方便，省了折腾那些花里胡哨的工具的时间多写两个BUG它不香么？😕

别再用JSON配置文件了

一开始 我犯了个错

为什么要使用JavaScript配置

轻松覆盖

动态配置

共享配置

注释

可测试

总结

一开始我犯了个错