一文大白话讲清楚啥是个webpack

1. 先讲故事，为什么需要webpack

• 作为前端开发者，我们是不是遇到过这个问题，因为业务逻辑比较繁多，导致单个js文件变得复杂且冗长，开发和维护起来特别的低效。于是，我们单个js拆分成两个js，然后在页面内通过script进行引入。
• 这么做虽然从代码角度上进行了拆分，单个js的文件变小，但是新的问题又接踵而来
• 首先就是全局污染问题。因为这些拆分出来的文件其实都运行在全局环境中，不仅不同文件的变量会发生冲突，而且会造成全局变量的污染
• 其次，单个文件之间没有依赖关系，只能严格限定script标签引入的顺序来控制变量的使用权限。
• 还有很多的问题，尤其当项目复杂度变高时，所有的问题会变得更加尖锐
• 随后，陆续出现了一些优化的手段
• 比如不久就出现了命名空间，说白了就是把单个文件的内容包裹在一个对象里面，然后挂在window上

window.moduleSingle={
    name:'tom',
    sayName:function (){
        console.log(name)
    }
}

• 1
• 2
• 3
• 4
• 5
• 6

• 这种手段一定程度上缓解了变量冲突的问题，但是像模块依赖这样的问题还是没有得以解决
• 于是又出现了IIFE，也就是自执行函数，通过自执行函数传参的方式，传入其他依赖

(function ($){
    /*这里通过$既可以访问jQuery*/
})(jQuery)

• 1
• 2
• 3

• 这种手段一定程度上缓解了模块依赖的问题，但是因为script引入不受代码的控制，无法做到按需加载，而且容易出现阻塞等问题
• 于是又出现了非标准化的模块化规范，比如CommonJS
• 通过exports暴露接口，再通过require引入接口
• 紧接着ES6将模块标准化，出现了ES Modules
• ES Modules完美的解决模块的按需加载等问题，但是新的问题又出现，就是ES6兼容性问题，我们是多么的希望通过ES6来高效的开发，然后运行的时候，对于不兼容ES6的，我们再把ES6转化为ES5去执行
• 所以就需要这么一个东西能出现
• 当然，不止这么一个需求，随着前端项目的复杂性变高，我们的对前端开发的要求也越来越高，

1. 我们希望通过标准模块化来完成开发
2. 我们希望在开发的时候使用一些像ES6，Typescript这样的高级特性来加速开发
3. 我们甚至希望在开发的时候提高调试的便捷性，不再是开发保存刷新看结果，看是开发保存，直接看结果
4. 在js实现模块的同，我们希望其他文件像HTML，CSS甚至一些静态文件也能实现模块化
5. 我们希望有一写工具能协助我们开发，比如对代码进行压缩合并等
6. 等等

• 这些需求是切切实实存在的 ，也是亟待解决的，于是大哥出现了，他就是今天的主题webpack4

2. Webpack

• webpack最初的目标是实现前端的模块化，他只能对js模块进行打包管理，但随着loader和plugin的加入，他可以高效的管理和维护前端项目中的每一个资源
  

• 怎么管理，看下文

2.1 模块打包

• webpack将项目中的所有文件（js文件，CSS文件，VUE文件等，在webpack眼中都是模块）当做一个整体，通过依赖关系（简单理解为就是谁用了谁，比如a.js 通过import引用了b.js的变量，那他两就存在依赖关系）将他们打包成一个或者多个静态资源文件，比如常用的bundle.js

2.2 依赖管理

• Webpack可以分析各模块的依赖关系，然后根据入口文件找出所有的以来模块，将其整合打包

2.3 文件转换

• Webpack自身只能处理js文件，但是可以通过loader的使用，将其任何文件如VUE文件，PNG图片等转化为有效的模块，使其能被打包到最终的静态资源中

2.4 代码拆分

• webpack支持将代码拆分成不同的模块，然后按需加载，提升性能

2.5 插件系统

• webpack生态系统了大量的插件系统，可以利用插件完成各种功能，比如代码压缩等

2.6 代码转译

• webpack可以配置babel，将ES6代码转化为ES5代码，提升代码的兼容性

3. webpack具体怎么用

• 看下一篇文章
• 一文大白话讲清楚webpack基础用法