使用config来管理配置文件
发布于 9 年前 作者 i5ting 31594 次浏览 最后一次编辑是 8 年前 来自 分享

使用config来管理配置文件

https://github.com/lorenwest/node-config

下面是一个比较简单的weixin公众号api配置的实例

执行命令:

npm install --save config
touch config/default.json

配置config/default.json内容

  "wx": {
    "app_id": "wx04014b02a0",
    "app_secret": "cc4c224b5018370cf6ffc95",
    "wx_menu": {
      "button": [
        {
          "name": "xxxxx",
          "sub_button": [
            {
              "type": "view",
              "name": "xxxxx",
              "url": "http://www.xxxxx.com/"
            },
 

实际调用代码

var API = require('wechat-api');
var config = require('config');

var menu_config = config.get('wx.wx_menu');
var app_id      = config.get('wx.app_id');
var app_secret  = config.get('wx.app_secret');

var api = new API(app_id, app_secret);

//测试
function app(){
  api.createMenu(menu_config, function(err, result){
    console.log(result);
  });
}

module.exports = app;

上面是比较常见的,还有像数据库配置啊等等

最佳实践应该是

  • 敏感信息放到环境变量里
  • 不敏感的配置信息放到config.json里

更好的一点是config支持各种模式

  • production
  • developmeng
  • test
  • staging

比如production模式下,config目录下创建config/production.json就可以了,真是太方便了。

注意json要格式化,最好的办法是

[sudo] npm install -g je
je

把json放里面格式化去

18 回复

这种与直接使用config.js做配置文件(就像cnnode源码的config.js一样),相比 好处在哪里呢. 感觉config.js更加直观好用轻便.

其实配置文件这块可以参考 kraken.js 已经做得很好了~~我用得很舒坦~

@nswbmw 给个star

@nqdy666 配置就应该是配置,而且cnode里的config.js是带有逻辑配置,其实是偷懒的行为

@okoala 这个不错 已收藏 多谢

nodejs里一旦修改了config.js 数据需要重新启动运行nodejs app吧? config.json 这种封装的方式,许改配置后也需要重新启动吗?

我使用xml进行配置,因为xml修改了,不需要重新启动nodejs

@SFLAQiu 你说的可以采用live-path结合,就可以动态载入了 https://cnodejs.org/topic/553723e548636414313a7398

@alsotang 引用: 配置就应该是配置,而且cnode里的config.js是带有逻辑配置,其实是偷懒的行为

确实是这样子的么?

@nqdy666 由于动态语言表达很简短,所以都倾向于在配置里面直接用该编程语言来配置,也经常融入逻辑代码在里面。

我并不认为配置就不应该有逻辑,把配置与实际的应用解耦不代表着配置就不能有逻辑,只要这部分逻辑与应用是松耦合的就好了。

@alsotang 你也懂rails,rails的配置里面有逻辑么?ruby不是脚本语言么?

和 dotenv 有什么区别?

@i5ting cnode 配置文件中的哪些地方在你看来是带有逻辑的?

@alsotang 你自己说的

也经常融入逻辑代码在里面。

我说你在cnode的config.js是偷懒的写法,不是纯配置文件,比如yaml,json, xml这些,写在js真就只有调用方便一条好处

@i5ting 但我也确实没感觉到这么写的坏处…

@alsotang 没坏处,而且很方便

但是你看这个前端,js的大发展,各种抽象,各种思想融合,其实就是在做各种分离

  • mvc
  • mvvm
  • ioc
  • aop
  • template
  • virtual dom
  • 或者其他基于component想法的,比如t3

都是在各种拆,各种分解,笼统一点说是“单一职责”吧,骚包一点说就是“solid”

ruby其实也可以这样写,但rails没有这样做,是吧?

回到顶部