现状
随着互联网发展，现在越来越多的网站已经从网页模式走到了webapp的模式。使用了很多H5,css3,es6等新技术开发更加丰富的功能，现在的网页已经 不单单是满足一个浏览的需求，而是要满足很多应用功能的需求，这就导致我们需要用异步的方式去加载更多的视图，这个过程中势必需要加载更多的 JavaScript代码，这就给前端资源组织带来很大的挑战。
我们知道前端资源是通过增量加载的方式运行到浏览器，如何在开发环境下组织好这些碎片化的代码和资源，保证他们在浏览器快速，优雅的加载和更新 就需要一个模块化系统，这个理想中的模块化系统是前端工程师一直探索的难题。
模块化系统的演变
-
script 标签
这是最原始的JavaScript文件加载方式。
早期为了解决这些弊端一些复杂的框架会使用命名空间来组织这些模块接口，典型的YUI库。 这个过程https://github.com/seajs/seajs/issues/547这篇博客讲的不错，可以了解。
这种方式暴露显而易见弊端：
- 全局作用域下变量冲突
- 文件只能按照script 标签书写顺序进行加载
- 开发必须主观解决模块间的依赖关系
- 在大型项目中各种资源难以管理，长期积累的问题导致代码库混乱不堪。
-
CommonJS
详情见我的博客 commonJS规范
缺点：
- 同步加载模式不适用于浏览器
- 不能非阻塞并行多个加载
-
AMD
详情见我的博客 AMD
-
CMD
-
ES6module
期望的模块系统
-
前端模块要在浏览器执行，所以他们需要增量加载到浏览器中。模块的传输和加载 我们首先能想到两种极端的方式，一种是把所有模块都打包到一个文件中只请求一次， 另一种是每个模块文件都单独请求，显而易见两种方式都不够完善，请求过多会启动变慢，一次请求全部，暂时用不到的模块也请求过来了，导致流量浪费 响应也会变慢。 我们所期望的一种模式是：按需进行懒加载，在实际用到某些模块的时候在进行增量跟新。
-
可以兼容样式，图片，字体等众多类型模块资源。
如何做到我们期望的： 在编译阶段，对整个代码进行静态分析，分析出各个模块的类型和他们的依赖关系，然后将不同类型的模块提交给适配的加载器处理 比如一个用less 写的样式模块，可以先用less 加载器将他转换成 css模块，再通过css模块把他插入到页面的 style 标签中执行。webpack 就在这样的需求中 诞生。
webpack
webpack 是一个模块打包器，他将根据模块的依赖关系进行静态分析，然后将这些模块按照指定的规则生成对应的静态资源。
这里提一下webpack和grunt gulp 有什么不一样：
grunt 和 gulp 的工作方式是 ：Grunt和Gulp的工作方式是：在一个配置文件中，指明对某些文件进行类似编译，组合，压缩等任务的具体步骤，这个工具之后可以自动替你完成这些任务。
Webpack的工作方式是：把你的项目当做一个整体，通过一个给定的主文件（如：index.js），Webpack将从这个文件开始找到你的项目的所有依赖文件，使用loaders处理它们，最后打包为一个浏览器可识别的JavaScript文件。
webpack特点
-
代码拆分
webpack有两种组织模块依赖的方式，同步和异步。详情见 webpack Code Splitting
-
loader
loder转换器可以将各种类型资源转换成JavaScript模块。这样任何资源都可以成为webpack可以处理的模块了。
-
智能解析
webpack 可以处理几乎所有第三方库，无论他们是CommonJS ，AMD 还是普通js文件，加载的时候可以用动态表达式。
-
插件系统
webpack 有丰富的插件系统。
-
快速运行
webpack 使用异步i/o 和多级缓存提高运行效率。使得webpack 能够以难以置信的速度增量编译。
webpack 安装
全局：npm i webpack -g
本地：npm i webpack –save-dev