简化一下 module.conf 中 combine 的配置逻辑

[leeight]

现在配置模块合并的工作，需要写不少的代码，例如我想配置dep和startup两个模块的话，就需要写如下的代码：

var dep = [
    base,
    echarts,
    negative(invalid)     // 不合法的amd，需要去掉
];

var startup = [
    bizCommon,
    negative(base),       // common/dep里面已经包含base的代码了，这里就不需要了
    negative(echarts),    // common/dep里面已经包含base的代码了，这里就不需要了
    negative(invalid)     // 不合法的amd，需要去掉
];

var combine = {
    'common/dep': {
        modules: compact(dep)
    },
    'startup': {
        modules: compact(startup)
    }
};

return combine;

这里面比较纠结的事情是一直在重复negative相关的代码（因为前面的模块合并了，其它的模块就不要再合并），为了
简化这个事情，我打算这么做，支持.v2这个配置参数来识别是新的格式（因为模块名不太可能是.v2开头吧）

{
  "combine": {
    ".v2": true,
    "exclude": [
      "~er", "xxx", "foo", "bar/**"
    ],
    "modules": [
      {
        "ria": [
          "~er", "~esui"
        ]
      },
      {
        "startup": [
          "~foo",
          "~bar"
        ]
      }
    ]
  }
}

因为modules是一个数组，所以可以按照顺序来处理。合并完毕ria之后，ria包含的模块Id默认就变成了startup
的exclude配置，这样子来简化上面negative的重复写法。

另外新增了一个exclude这个是针对所有modules里面配置的模块生效的，目的是简化negative(invalid)的写法。系统中
总会存在一些不太符合 amd 要求的文件，我们在发布的阶段需要忽略掉这些文件。

[otakustay]

感觉上可以用，但直觉上是会有问题的，比如我有startup/foo和startup/bar，分别是用在2个页面里的，那么它们是不应该互斥的

回到最初的问题，我认为是不是这样就能解决：

combine = {
  foo: {
    modules: [...]
  },
  bar: {
    modules: [...], // 这里不要去管是否会重复
    negative: ['foo'] // 表示要把`foo`里有的去掉
  }
}

当然这样如果有N个配置，还是要写一些negative配置，只是相比之前的一堆自己写要简单也逻辑清晰

[leeight]

foo和bar如果是 key 的话，那么执行的顺序是不太容易保证的。万一 bar 先执行了 或者 foo negative bar 并且 bar negative foo，我感觉好像是一个很麻烦的事情。

我有startup/foo和startup/bar，分别是用在2个页面里的，那么它们是不应该互斥的

是不应该互斥的，这里提到的foo和bar应该就是具体的某个 Action 了，他们应该把 公共代码中的 模块id 排除掉。

{
  "combine": {
    ".v2": true,
    "exclude": [
      "~er", "xxx", "foo", "bar/**"
    ],
    "modules": [
      { "ria": [ "~er", "~esui" ] },
      { "startup": [ "~foo", "~bar" ] },
      {
        "negative": ["ria", "startup"],
        "modules": [
          {"bcc/List": ["bcc/ListView", "bcc/ListModel"]},
          {"bcc/Form": ["bcc/FormView", "bcc/FormModel"]},
        ]
      }
    ]
  }
}

[errorrik]

太复杂了，combine的object里有modules item，里面每个module还有modules item，看着都哭了

[errorrik]

[leeight]

这应该不是最终的样子，只是用来说明一下采用的方式吧

[otakustay]

我想的是这样的效果：

var combine = {
    'base': {
        include: ['jquery', 'underscore']
    },
    'startup/foo': {
        include: ['foo/**'],
        negative: ['base']
    },
    'startup/bar': {
        include: ['bar/**'],
        negative: 'base'
    },
    'lazy/fooDetail': {
        include: ['detail/foo/**'],
        negative: ['foo']
    }
}

上面的表示：

1. 有一个base包含基础库
2. foo和bar分别用于2个html页面，所以它们各自有自己的策略，但都不要base
3. fooDetail用于在foo.html中点击某个按钮时要加载的模块，所以它不要foo，同时因为foo不要base，fooDetail也就隐式地不要了base

[errorrik]

我理解 @leeight 的意思，是希望很多combine的模块里，公共的部分能有地方去进行统一配置。但是我觉得，combine是一个Object，每一个key代表一个希望被合并的module，这点最好还是不要变，否则会不太好理解。

可以为每个希望被合并的module，增加一些项，这些项在modules处理后的集合中进行处理。参考了下rjs，我觉得，可以有：

• includes: 要引入的模块，包含其依赖
• includeShallows: 要引入的模块，不包含其依赖
• excludes: 要排除的模块，包含其依赖
• excludeShallows: 要排除的模块，不包含其依赖

这样，配置代码可能会变成这样：

var base = [sys-base, echarts];

var combine = {
    'common/dep': {
        modules: base
    },
    'startup': {
        modules: [bizCommon],
        excludes: base
    }
};

return combine;

[otakustay]

事实上不用数组，我们也可以根据每个配置项里的negative之类的属性，来算出顺序的，无非是一个依赖图，把这个交给程序更合适。用数组并且前后negative关系反了是会很麻烦的，甚至问题都排查不到

[errorrik]

事实上不用数组，我们也可以根据每个配置项里的negative之类的属性，来算出顺序的

没理解

[leeight]

立理指的应该是先处理哪个后处理哪个的问题

[otakustay]

没理解

我是基于你的观点进行的补充，我也认为使用数组其实不是太合适，保持原有的对象的模式，让程序来计算这些对象间的互斥关系，进而决定build的顺序即可

[leeight]

1. 那就保持对象的模式吧，也可以
2. 新增一个negative应该就可以了，多重复几次就多重复几次吧，不过看起来会更清晰。
3. includeShallows和excludeShallows我感觉好像意义不是很大耶。

最终推荐的配置应该就是这样子了吧？

var combine = {
    'base': {
        modules: ['jquery', 'underscore']
    },
    'startup/foo': {
        modules: ['foo/**', '!foo/bar'],
        negative: ['base']
    },
    'startup/bar': {
        modules: ['bar/**', '!bar/foo'],
        negative: 'base'
    },
    'lazy/fooDetail': {
        modules: ['detail/foo/**'],
        negative: ['foo']
    }
}

[errorrik]

我建议还是不要叫negative，毕竟negative这个单词还没在edp或者rjs里出现过。叫exclude或者excludes？

[errorrik]

关于includeShallows和excludeShallows，有时候还是有意义的。我为echarts写optimizer的时候就遇到了适用的场景。在项目的build中，excludeShallows的意义比includeShallows大些。不过我觉得可以不加，以后遇到在加好了

[leeight]

叫exclude或者excludes？

include和exclude最早就已经被用掉了，现在exclude的实现貌似就是excludeShallows的意思，只把本模块排除掉（实际上也就把它依赖的模块也间接的排除了）。如果继续采用exclude的话，貌似就需要让他扮演真正exclude的意思（把它以及它依赖的模块都排除在外？）

[errorrik]

@otakustay 主席给点意见？