webpack模块依赖管理介绍

http://webpack.github.io/docs/

webpack is a module bundler.

• 是一个模块管理器
• webpack可以管理模块的依赖关系，并产生可以替代这些模块的静态代码

已有方案 V.S. Webpack

• <script>:

• • <script src="module1.js"></script>
    <script src="module2.js"></script>
    <script src="libaryA.js"></script>
    <script src="module3.js"></script>

  • 冲突，加载顺序，依赖，长且难于管理
• commonjs（同步）：

• • require("module");
    require("../file.js");
    exports.doStuff = function() {};
    module.exports = someValue;

  • 网络同步请求块级调用不适用，多模块无法并行调用
  • 实践：nodejs，browerify，modules-webmake（编译成为一个bundle），wrep（客户端）
• AMD（异步）：

• • require(["module", "../file"], function(module, file) { /* ... */ });
    define("mymodule", ["dep1", "dep2"], function(d1, d2) {
      return someExportedValue;
    });

  • 适用于网络异步模型，多模块并行加载
  • 代码过重难于读写，更像是为了解决问题的变通方法
• ES6 MODULES：

• • import "jquery";
    export function doStuff() {}
    module "localModule" {}

  • 易于静态分析，确认为未来的ES标准
  • 原生浏览器支持需要时间，仅有很少模块采用这种形式
• webpack：
• • 让开发者选择模块风格，允许已有代码正常运行，易于添加用户模块类型

模块转移方案：

• 模块需要在客户端运行，所以模块需要从服务端转移到浏览器端
• 两种极端的转移方法
• • 一个请求一个模块
  • • 优点：仅请求需要的模块
    • 缺点：多模块请求次数过多
    • 缺点： 请求延时导致app打开过慢
  • 一个请求所有模块
  • • 优点：请求次数减少，请求延时减少
    • 缺点：不能够按需请求
• 模块组（chunked）转移：当编译所有模块时：将模块集合划分为多个小一些的模块组。
• • 通过这种方法我们得到多个更小的请求，初始化时不需要的模块组可以按需请求，初始化请求不在包含完整模块代码并且变得更小了。
  • 模块组的划分（代码分割）取决于开发者的需求并且是可选的。
  • 大量代码库成为可能。
  • GOOGLE’S GWT： http://www.gwtproject.org/doc/latest/DevGuideCodeSplitting.html
  • 更多代码分割资料： http://webpack.github.io/docs/code-splitting.html

其他资源依赖管理支持：

• 资源
• • 样式，图片，webfonts，html模板等
  • coffeescript，less样式表，jade模板，i18n文件
• 解决方案： Using loaders 和 Loaders

静态分析：

• 当编译全部模块的时候，静态分析系统会尝试找到对应依赖
• 现状：通常该系统只能找到没有表达式的简单依赖，但是表达式方式确是很常见的require("./template/" + templateName + ".jade")
• 解决方案：智能解析器允许大部分的已有代码正常运行，即使开发者做了什么奇怪的事情，解析器也会找到兼容性最好的解决方案。