这时模块a，模板b中的代码都暴露在全局环境中，如果模块a中定义了一个方法del。同学b并不知道，在模块b中也定义了一个方法del。这时便造成了命名冲突的的问题。如图

在 webpack 中，专注于处理 webpack 在编译过程中的某个特定的任务的功能模块，可以称为插件。它和 loader 有以下区别：loader 是一个转换器，将 A 文件进行编译成 B 文件，比如：将 A.less 转换为 A.css，单纯的文件转换过程。webpack 自身只支持 js 和 json 这两种格式的文件

因为 Webpack 是以模块化的 JavaScript 文件为入口的，所以内置了对模块化 JavaScript的解析功能，支持 AMO, Cornmo nJS SystemJS ES6 parser 属性可以更细粒度地配置哪些模块语法被解析、哪些不被解析。同 noParse 配置项的区别在于

该方式比较合适WebKit浏览器或移动端（绝大部分是WebKit内核的）浏览器。但是在现在一些框架中如(Vue,react项目中使用)，会发现本地正常，打包线上后，该属性丢失

webpack 是一个模块打包器，在它看来，每一个文件都是一个模块。无论你开发使用的是 CommonJS 规范还是 ES6 模块规范，打包后的文件都统一使用 webpack 自定义的模块规范来管理、加载模块

webpack本身只能打包Javascript文件，对于其他资源例如 css，图片，或者其他的语法集比如jsx，是没有办法加载的。 这就需要对应的loader将资源转化，加载进来。

首先，Grunt和Gulp只能将一些CSS和JS文件分别压缩合并成单个文件，当然也具有一些编译功能，比如Less和Sass的编译、ES6到ES5的编译等等。但是Webpack不仅具有它们所具备的这些编译压缩合并功能，

之前尝试过一些在webpack3的基础上做的构建优化，例如引入HappyPack优化构建速度，开启loader缓存和优化包查找路径等等，详情可以查看前端webpack构建优化

PostCSS 本身是一个功能比较单一的工具。它提供了一种方式用 JavaScript 代码来处理 CSS。它负责把 CSS 代码解析成抽象语法树结构（Abstract Syntax Tree，AST），再交由插件来进行处理

许多项目脚手架默认就会把src目录添加一个@别名，项目中实际引入时，虽然可以精简路径，但也带来一个很麻烦的问题：IDE无法识别这些别名，因此导致无法自动完成路径、无法识别引用资源的输出、出现不必要的告警等情况。

引入utils文件,此处主要用到了assetsPath()方法,用来根据开发模式或生产模式来使用config文件下的相应配置，引入config文件夹下index.js,使用打包或开发配置

Webpack中loader是一个CommonJs风格的函数，接收输入的源码，通过同步或异步的方式替换源码后进行输出。需要注意的是，该导出函数必须使用function，不能使用箭头函数，因为loader编写过程中会经常使用到this访问选项和其他方法。

webpack ensure 有人称它为异步加载，也有人称为代码切割，他其实就是将 js 模块给独立导出一个.js 文件，然后使用这个模块的时候，再创建一个 script 对象，加入到 document.head 对象中，浏览器会自动帮我们发起请求

项目中引入了css文件，配置了 rules 中：在执行 webpack 命令时，发生错误，报错信息：Module build failed (from ./node_modules/css-loader/dist/cjs.js):CssSyntaxError,经查询，是loader顺序不正确导致此问题，修改后如下：

webpack-dev-server是一个让我们可以模拟线上环境进行项目调试的工具，主要功能有：路径重定向、浏览器中显示编译错误、接口代理 如解决跨域、热更新