环境变量相关配置的拆分和优化

[gbk]

目前环境变量的配置（vars/buildvars）

• 有一些隐性配置，比如自动根据变量的值组合生成后缀
• 只有两套环境（server 和 build）
• 不够灵活，只支持简单类型

考虑将环境相关的配置和端相关的配置拆开，换成以下的格式：

{
  "name": "test1",
  "options": {
    "entry": "app/app.js",
    "extVars": {
      "zh-cn": {
        "locale": "zh-cn"
      },
      "en-us": {
        "locale": "en",
      }
    },
    "envVars": {
      "dev": {
        "apiPrefix": "http://127.0.0.1:3000/api"
      },
      "test": {
        "apiPrefix": "http://192.168.1.101/api"
      },
      "prod": {
        "apiPrefix": "https://api.alibaba-inc.com/api"
      }
    }
  }
}

执行 nowa server --ext zh-cn 可使用 extVars['zh-cn'] 的变量组合构建出 app-zh-cn.js， 执行 nowa server --env dev --ext zh-cn 可使用 envVars['dev'] + extVars['zh-cn'] 的变量组合构建出 app-zh-cn.js。 ext 和 env 参数都包含了构建的环境变量，区别在 ext 决定了 entry 的后缀。 nowa build 不指定 ext 时候，会将所有 extVars 变量组合构建出来， ext 和 env 不指定的时候默认使用配置的第一项。

[LiangZugeng]

把环境独立出来是合理的，也是很多开发框架的标准做法，此提议的方案增大了灵活性，个人对于设计还有两点建议： 1、建议build时根据不同环境新建对应的目录，把每个环境编译的output全部输出一遍（比如html/css/scripts等），方便做continuous delivery。 2、建议增加对于index.html这类静态文件的环境变量支持，比如内容里面如何将app.js根据不同环境替换成不同的编译后的文件如app-dev.js等。

[gbk]

1. 不太同意，持续集成一般只构建 test 环境的就行了啊，test 和 prod 不会有逻辑上的差异
2. 好主意！已排上日程，会在这里跟踪

[LiangZugeng]

1. 不是持续集成，是持续交付，构建出来多个配置的版本，testing版本先推到testing环境，测试验证，没有问题自动推送staging版本到staging环境进行产品验证，再没有问题自动推送production版本到生产服务器。所以在这种交付模式下需要构建同一个commit的多个配置的版本。

[gbk]

这样的话，建议跑三次命令呢，testing 构建产出验证通过再构建 staging……

nowa build --env test --dist test_output
...
nowa build --env staging --dist staging_output
...
nowa build --env production --dist production_output

[LiangZugeng]

谢谢，这样能解决我的问题。那从设计方面就没有太多要补充的意见了。