今天继续分享webpack的有关内容！
我还是接着从上篇文章的项目来给大家分享后续内容，如果还有小伙伴没有阅读之前的文章，请关注博主进行阅读！
1、webpack的规范配置；
2、webpack.config.js基础配置；
3、单页开发【单文件打包】；
4、多页开发【多文件打包】；
5、Glob配置动态入口打包多文件；
6、哈希Hash；
7、webpack、node 常用命令。
提到 webpack 的配置方案、插件等，相信很多小伙伴都有了解，网上也有很多关于webpack的配置说明，但都是参差不齐。博主会通过后续的几篇文章，陆续带大家对它进行全面剖析！
webpack的配置分为三个部分：
为了实现webpack的规范化配置，很多文章所分享的内容不一，今天带大家进行规范化配置webpack的开发环境，总体来说包括开发配置的三个部分，开发环境、生产环境、测试环境，
（1）开发环境：不名思意，就是开发者开发时所处的阶段环境，此阶段开发者将获得最好的开发体验，这些都是得益于webpack针对开发环境提供的特性：
♣ 浏览器调试工具
♣ 注释、开发阶段的详细错误日志和提示
♣ 快速和优化的增量构建机制
（2）生产环境：此阶段是项目正式上线的环境，需要开发者在项目上线前，进行一些系列的配置、调试。在生产环境阶段，同样 webpack 官方提供了针对生产环境的特性：
♣ 开启所有的优化代码
♣ 更小的bundle大小
♣ 去除掉只在开发阶段运行的代码
（3）测试环境：测试阶段是整个项目的关键所在，也是距离项目正式上线的最后一步，需要前后端人员进行模拟、验证、调试，以此确保项目正式上线后能正常运行。
今天重点讲解前两个部分，测试环境涉及一些重点内容放在后面讲。
webpack是一项静态资源模块打包工具，为了实现轻量化标准，webpack对其自身进行了很大优化，分离一些自身携带的非必要功能插件，其自身内部携带的插件功能还是十分强大的，同时也有一些第三方插件，提供 预处理、源码的适配、代码压缩、CDN缓存、模块开发等多个方面。
接下来我们的项目中会用到插件，协助我们更加快捷、高效的开发。
想必大家都清楚，你的项目从无到有，需要经历一个漫长的过程，在团队一步步的研发过程中，会越来越复杂，需要的配置逐渐增多，需要的标志就会越多。在一定程度上意味着工程的配置管理变得混乱，变得愈来愈难以控制。那么该怎么办？
理所当然，必须得有管理配置的文件（工程配置文件）出现，来解决这个问题，有清晰的思路，自然一切也就迎刃而解，接下来就是规范配置的第一步：创建配置文件
在根个目录下新建一个目录build，而后创建文件webpack.config.js，作为配置文件置于该目录下
用于对项目配置信息的管理，也是配置webpack要做的事情。
现在创建的文件是空白文件，作为配置文件，将会导出一个对象的 JavaScript 文件，需要进一步配置：
你以为就这样结束了吗？不，远远没有
Webpack 配置是标准的 Node.js CommonJS模块，通过require来引入其他模块，通过module.exports 导出模块，由 Webpack 根据对 对象定义的属性进行逐步解析。
以上很简单，到目前为止只是通过 entry设置了入口起点，然后通过output配置了打包文件的输出，发现还有其他模块没有配置，不要着急，脚踏实地一步一步来，后面会带大家把里面的内容补全，还有一点，随着后面的配置越来越来多，整个webpack也会越来越复杂。
完成以上配置后，进入到package.json包管理文件，并在scripts脚步命令配置模块添加
"build": "webpack --config ./build/webpack.config.js"按照上面这种方式处理，会极大地简化我们使用的命令，如上配置后，在终端可以执行
npm run build
执行上面的命令，可以在 dist 下面看到打包结果
上面的命令执行效果与前面提到的webpack src/index.js --output dist/bundle.js --mode none等同。同样有警告信息，主要是mode的配置没有添加。在上面的配置中添加:
"build": "webpack --config ./build/webpack.config.js --mode production"在原命令后面追加 --mde production
再次执行npm run build，不会再有警告信息。
可以看到上面都只是针对单文件打包，那么问题来了，
在实际项目开发过程中，随着模块增多、功能多样化需求，导致需要依赖的文件越来越多，其中多文件打包是必然要考虑的一个问题，究竟该如何处理？（小伙伴们可以把自己的想法展现在下面评论区）
下面博主给大家分享几种多文件打包的方式：
上面是但文件打包，必须使用path.resolve来生成相对于当前目录的绝对路径，作为入口文件；
之所以要给大家分享多文件打包方式，是因为项目中不同的功能模块都是需要各自独立开发的，避免互相影响，会出现有多个入口文件的情况，此时多文件打包的优势是不是瞬间就体现出来了！
多文件打包：
进行多文件打包之前，需要提前创建几个需要打包的 JS 文件
方式一：多文件合并打包
entry:["../src/test.js", "../src/main.js"],
output: {
path: DIST_PATH,
filename: 'bundle.js'
}方式二：多文件独立打包
entry: {
main: "../src/main.js",
test: "../src/test.js
},
output: {
path: DIST_PATH,
filename: '[name].js'
}方式三：多文件独立打包（其他方式）
注意：使用之前，需要插件 glob 的配合。
Glob 插件，使用此插件可以配置动态的文件入口，提供多个文件打包的独立输出。
Glob 插件属于非官方插件（第三方），使用之前，需要安装：
npm install glob@7.1.7 --save-dev
由于插件更新较快，所以可以根据自己需求安装任何版本。
安装成功以后，需要在配置文件中引入模块，然后配合使用
var glob = reuqire("glob");借鉴第二种方式，对第三种的文件打包方式做一个提升：
既然文件独立打包，入口文件必须是一个键值对的形式，那么我们可以试着往这个点去扩展，
在全局做一个处理，对需要打包的文件通过键值对形式存入到对象中，赋值给入口就行了！
顺着这个思路，我们接着往下处理：
首先，需要找到待处理的文件路径；
var webpack = require("webpack");
var path = require("path");
var glob = reuqire("glob");
var DIST_PATH = path.resolve(__dirname, "../dist");
var SRC_PATH = path.resolve(__dirname, "../src");
var newEntries = {};
// var files = glob.sync(path.join(SRC_PATH, "/*.js"));
var files = glob.sync(SRC_PATH + "/*.js");
其次，通过循环查找遍历出每个文件；
然后，对遍历出的每个文件的相关信息进行提取，作为 KEY：VALUE形式；
file.forEach((file, index) => {
// file-name
var substr = file.match(/src\/(\S*)\.js/);
// add
newEntries[substr] = file;
});最后，放入一个目标对象中，作为入口即可。
module.exports = {
entry: newEntries,
output: { // Webpack所创建的bundle文件
path: DIST_PATH,
filename: '[name].js' // 多文件独立打包
},
// 模块解析
module: {},
// 插件
plugins: [],
// 开发服务器
devServer: {}
};以上四个步骤，是我们处理多文件独立打包输出的一种方式，还有很多方式，小伙伴也可以积极思考，有想法可以在下面评论区回复博主哦！
项目做到此处，不知道小伙伴们对上面的内容掌握了多少？
接着，我们可以试着修改/src/main.js的代码：
alert(`Hello, Webpack! Let's Go`);
重新编译之后，打开/dist/index.html你会发现浏览器会弹出alert()框：
为了开发方便，不可能通过node或其他类型的即时服务来启用一个服务。我们可以把这部分事件放到开发服务器中来做，对应的就是devServer，所以我们接着在webpack.config.js中添加devServer相关的配置：
webpack-dev-server 插件：
webapck-dev-server 是可以一款快速搭建本地运行环境的工具。webpack-dev-server 是一个小型的 NodeJS + Express 服务器，它使用 webpack-dev-middleware 来服务于webpack包，此外，它还有一个 Sock.js 来连接到服务器的微型运行时。
命令简单 webpack-dev-server 或配置命令脚本快捷运行，模拟服务器运行情况，进行上线之前的调试。
使用需要安装：npm install webpack-dev-server --save-dev
webpack-dev-server 与 webpack-dev-middleware究竟是什么？
webpack-dev-server：
webpack-dev-server 相当于启动了Express 的HTTP服务器+调用webpack-dev-middleware。这个 HTTP 服务器和client 使用了websocket 协议，在原始文件做出改动之后，webpack-dev-server会使用webpack实时编译，再用webpack--dev-middleware将webpack编译后的文件实时输出到内存中。
适合纯前端项目，很难编写后端服务，进行整合。
webpack-middleware：
webpack-dev-middleware 输出的文件存在于内存中。
你定义了 webpack.config，webpack 就能据此梳理出 entry 和 output 模块的y依赖关系，而 webpack-dev-middleware 就在此基础上形成一个文件映射系统，每当应用程序请求一个文件，它匹配到了就把内存中缓存的对应结果以文件的格式返回给你，反之则进入到下一个中间件。
因为是内存型文件系统，所以重建速度非常快，很适合于开发阶段用作静态资源服务器；因为 webpack 可以把任何一种资源都当作是模块来处理，因此能向客户端反馈各种格式的资源，所以可以替代HTTP 服务器。事实上，大多数 webpack 用户用过的 webpack-dev-server 就是一个 express＋webpack-dev-middleware 的实现。
二者的区别仅在于 webpack-dev-server 是封装好的，除了 webpack.config 和命令行参数之外，很难去做定制型开发。而 webpack-dev-middleware 是中间件，可以编写自己的后端服务然后把它整合进来，相对而言比较灵活自由。
了解上面这些知识点后，我们来配置开发服务器：
devServer: {
hot: true,
contentBase: DIST_PATH, // 需更新的目标目录
host: 'localhost', // 主机地址，默认是localhost，你也可以指定地址
port: 8080, // 端口
historyApiFallback: true,// 该选项的作用所有404都连接到index.html
// info: true, // 只针对Cli，默认是启用的，不要随意设定，否则项目启动不了。
noInfo: false, // 是否需要实时显示并输出打包信息
proxy: { // 代理
"/api": "http://localhost:3000" // 拦截所有以api开头的请求地址，代理到后端地址
}
}以上的几个是最常用的配置项，还有很多配置项，小编就不再一 一介绍了，有疑问可以在评论区回复！
对开发服务器配置完毕之后，还没有结束，需要在package.json文件中配置快捷启动服务的命令，
"scripts": {
"dev": "webpack-dev-server --config ./build/webpack.config.js",
}做完上面这些处理之后，在dist目录下新建一个html文件，script方式引入JS文件，尝试使用下面的命令来启动项目，
npm run dev
这是我们正常启动后的界面：
既然项目配置了热启动，那么我们尝试修改src/main.js中的内容，检测热启动是否会实时刷新并渲染页面，在JS文件中添加如下代码：
document.addEventListener("DOMContentLoaded", function(ev){
var dom = document.createElement("div");
document.body.append(dom);
dom.innerText = "Hello Webpack ^_^ !";
dom.style.color = "#f46";
});
根据上面的场景测试后，发现无需手动刷新，浏览器会自动刷新并渲染页面。
下面，我们来思考一个问题：
我们的项目开发时，其中的文件在不断变化，等项目正式上线后，开发人员需要不断地迭代优化更新我们的项目文件，那么这个时候，我们需要对修改过的文件做标记，便于客户端从服务器拉取数据，更新CDN缓存，那么hash就可以满足我们这一需求。
那么如何设置文件的hash呢？
需要在我们的配置文件中做设置，还记得文件的输出吗，output出口 正是对我们打包文件输出的配置，需要对文件的名称做出改变，添加 hash，
filename: '[name][hash:8].js' // 设置 hash 值这样处理 文件的hash值，虽然目的达到了，但是也会存在缺点，我们不推荐使用hash，建议用chunkhash：
原因：
1、使用 hash，并且使客户端做了CND缓存，如果修改了某个/某几个JS文件，则会导致所有文件的 hash 发生变化并且所有文件再产生一个hash文件（相当于备份的形式但每个文件的 hash值 不一样）；虽然把 hash 做了变化，但是对CDN缓存没有起到任何作用，还把文件名字改了，这样做客户端的CDN缓存根本无法识别究竟 是哪些文件做了改变，哪些没有改变，也就无法服务端拉取数据，更新缓存；
2、使用 chunkhash，只会修改被改动的文件的 hash 值）
为了更形象，我给大家放两张图，说明一下hash的缺点：
从上面两幅图可以看出，无论是否修改源文件，再次打包都会修改hash值，并创建备份。
另外，还以一种hash格式——contenthash
它主要针对 CSS 文件，不会因为JS文件引用了某个/某些 CSS 文件，而导致CSS文件的哈希值发生改变。
我们依然两幅图来说明 contenthash：
从上面两幅图可以看出，只有发生改变的源文件，再次打包才会修改hash值，并创建备份，反之，没有发生改变的源文件的hash是不会发生改变的。
一般我们在项目中，sass、less等其他格式的样式文件，都会通过打包到JS文件加载到页面中，
有时候我们是需要做缓存的，把他们抽出为一个单独的 CSS 文件，抽出CSS就是为了做CDN缓存，有些文件的CSS样式是不需要修改的，把它们抽离出来单独放到一个文件，这样可以提高用户访问产品的性能。
在chunkhash的例子，我们知道由于index.css被index.js引用后加载到页面中，所以共用相同的chunkhash值。
但是这样子有个问题，如果index.js更改了代码，css文件就算内容没有任何改变，由于是该模块发生了改变，导致css文件会重复构建。
这个时候，我们可以使用 extra-text-webpack-plugin里的contenthash 值，保证即使css文件所处的模块里就算其他文件内容改变，只要css文件内容不变，那么不会重复构建。
项目打包之前需要删除某个文件夹之后，再执行打包，需要插件 rimraf的使用，使用之前也是需要安装该插件：
npm install rimraf --save-dev
dist文件夹在每次项目打包的时候都会有非常多的文件，需要删除后重新打包，那么就可以使用它来配合实现。
在package.json中的打包命令同样也要配置：
"build": "rimarf dist && webpack --config ./build/webpack.config.js --mode production",
以上的文件删除命令，Node中的删除文件命令同样可以使用，可以不同安装插件
"build": "rm -rf dist && webpack --config ./build/webpack.config.js --mode production",
好了，各位小伙伴，今天博主的分享到此结束了，下一期是 webpack 的优化篇！
再次感谢各位的支持，如果对博主文章满意的话，请给点个赞哦 ^_^！