这一章考察模块的打包是如何被两个未来开发环境影响：HTTP/2和本地化模块。
打包模块意味着拼合几个以模块形式存在的文件到一个文件中。因为三个原因那样做：
- 更少的文件需要被取回来加载所有的模块。
- 压缩被打包的文件比打包多个文件更略微高效一些。
- 在打包期间，没用到的导出能被移除，潜在地导致在空间节约上效果显著。
伴随ECMAScript6，JavaScript终于得到了内置模块（我在这章中称它们JavaScript模块作知会）。然而，那个特性现在却处在一个奇怪的位置：
一方面来说，ES6完全使它们的语法和它们的语义标准化。它们成为了一个书写各模块的知名规范并且它们的静态结构使得自动删节无用的导出（同时以“tree shaking”在JavaScript世界中闻名）。
另一方面来说，规范化如何去加载JavaScript模块是正在发展并且还没有JavaScript引擎本地化地支持它们。那意味着它，此时此刻，唯一使用JavaScript模块的途径是编译它们到一个非本地化的格式。致命的解决方式是：browserify，webpack，jspm和Rollup。
让我们一起看下两个未来开发环境以及它们是如何影响JavaScript模块的打包的。
HTTP/2缓慢地被铺开。它主要地影响原因第一是对于打包：伴随HTTP/2，每个请求的花费被相比于HTTP/1相当地减少了，这意味着实际上如果你下载单个文件而不是多个来说没有表现上的收益。它使得更小的，更增量的更新：伴随着打包，你总是需要下载整个绑包。不使用打包，你只需要下载发生了变化的那部分。（同时其他部分常常还继续保留在浏览器缓存中）。
不过，对打包来说的原因2和原因3不会被HTTP/2搞失效。因此，混合的途径在未来被接受，来对增量的更新和更小总下载尺寸的优化。
一旦各引擎支持本地化JavaScript模块，它们将会影响打包？甚至AMD模块——那些在浏览器中本地化运行的——有一个定制化的打包格式（连同一个极小的加载器）。本地化JS模块将会不一样吗？看起来他们将会。Rollup让你打包多个JS模块到单个JS模块中。
拿着，一个例子，这两个JS模块：
// lib.js
export function foo() {}
export function bar() {}
// main.js
import {foo} from './lib.js';
console.log(foo());Rollup能打包这两个JS模块到接下来的一个JS模块中（注意移除的无用的导出bar）：
function foo() {}
console.log(foo());最初，它不是一个JavaScript模块要以一个打包格式运作的假设——引自Rollup的创造者Rich Harris：
当我开始书写Rollup，它是我并不确定能成功的一个试验。
导入的方式是由JS模块处理对打包有帮助：它们不是导出的拷贝，它们是在它们的只读视图。
Rollup的网站有一个有好的你能试验它的交互玩乐场所。
-
“为HTTP/2构建”来自Rebecca Murphey（阐述实践中的改变有多美好——常常是激进的——伴随着新版的HTTP）
-
“探索ES6”的章节“模块”（阐述ES6模块如何运作）
-
本书中的章节“Babel和CommonJS模块”（阐述Babel如何确保代码翻译的各ES6模块适当地交互操作）
首页：架设ES6
上一章：Babel和CommonJS模块