在 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访问选项和其他方法。

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

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

nodejs的出现对于构建工具具有重要的意义，在没有nodejs之前，js只能执行在浏览器环境下，所以意味着对发布前的js文件要进行处理，十分局限，没有打包工具，只能用PHP脚本来处理文件

webpack 是一个现代 JavaScript 应用程序的静态模块打包器（module bundler）。当 webpack 处理应用程序时，它会递归地构建一个依赖关系图（dependency graph），其中包含应用程序需要的每个模块，然后将所有这些模块打包成一个或多个 bundle