被遗忘的技术细节现在 require 入口调用，会自动把其同步依赖加载进来。但是，等等，貌似怪怪的，因为 require 入口的调用其语义就是异步调用，怎么变成同步的语义了？ 按语义来应该针对 require(‘deps’) 引用做同步处理，但是这种用法并不在 amd 规范中定义，amd 规范定义的同步调用用法，只出现在模块定义内部。所以没办法，把模块定义外的 require 用法当成同步来用吧（模块定义内部的 require 异步语义保持不变）。当然一定要当作异步来用也是可以的，只要在 require 调用的前面加段注释 fis async。这样编译期就会把找到依赖标记成异步依赖。 由于 FIS 对于静态文件是支持打包合并、加 md5 戳和部署到 cdn 的，也就是对于 js 的引用，我们是要忽略他的 release 后的路径的。如果纯同步依赖，似乎没问题，但是异步依赖怎么办呢？我在 require 里面的 module id 当然还是得用源码路径ID方便调试定位。 那么怎么转换路径呢？ 原来 mod.js 方案是读取 amd 方案里面也是采用同样的方式，只是利用的是 amd 规范中的 paths 设置，根据 map.json 自动生成程序中所需要的异步依赖的路径转换规则，这样的话，fis 不是一定只能用 mod.js 才能做模块化开发，以后换成其他所有的 amd loader，比如还有 ecom 出的 esl.js;
另外，amd 依赖解析插件 除了解析依赖，实际还会做一个小优化，就是会把 factory 中的各种依赖，提前放置在 define 的第二个参数里面。这样的好处是， amd loader 再也不要用正则查找 factory 函数体的 require 了，直接读第二个参数就能把所有依赖拿到。 总结既然 fis 在编译 amd 模块的时候，优化了这么多，依赖处理啊， ID 生成啊之类的。那么我们还需要一个如此庞大的 require.js 吗？ 当然不需要，FIS 组结合编译的处理，提供一个最小 amd loader 叫 mod-amd.js 仅仅 200 多行, 但是他暂时不支持 amd plugin loader，因为没有足够的理由要去支持它，像模板加载，样式加载，fis 中有更优的处理方案。 好吧，回头正视原来提出的那些问题。
|
