dev-server，从名字就可以看出来，它是一个开发用的服务器。
dev-server 只在开发阶段用，那么我们为什么要用它呢？
1，帮我们提供网络环境。因为我们都知道 ajax，cookie 等等都是需要网络环境才能够测试的。
2，可以热更新。也就是说我们每次改了代码后不需要再重新编译，刷新页面了。只要它检测到我们的文件一变，立刻自动帮我们重新编译，然后推送给浏览器，浏览器那边也自动跟着变。非常便于我们的开发。
然后我们进入正题：
首先，我们仍然先初始化：npm init -y
然后我们下载 npm install webpack webpack-cli webpack-dev-server css-loader style-loader file-loader url-loader -D
webpack：核心，dev-server 需要它才能够跑起来。
webpack-cli：命令行的启动器，主要是 dev-server 里面的命令需要 webpack-cli。
webpack-dev-server：dev-server 核心。
然后我们再来完成项目的大致结构，以及 webpack.config.js 的基础配置：
那么我们怎么来启用 dev-server 呢，我们可以在 package.json 里面设置一个快捷命令：
所以我们当我们 npm run start 的时候，它就会自动的替我们启用 webpack-dev-server，并且自动的打开一个服务器：
可以看到，这个服务器是运行在 8080 端口上面。
其实我们将指令写在 package.json 里面是一个简写，为了方便。但是我们这个 dev-server 略有不同。
理论上来说，即使我们不用 npm run start，直接使用 webpack-dev-server，也是可以出来的：
但是我们会发现，它实际上出不来，说这不是个命令。
其实它真正的执行，根本就不是执行 webpack-dev-server，而是靠 webpack-cli 去找 webpack-dev-server。只不过 package.json 它因为会自动的解析 node_modules 里面的东西，所以它忽略了这点。
说白了，就是如果我们直接在命令行输入指令，它是会先去找全局的包。而如果是运行 package.json 里面的快捷指令，就是先找 node_modules 里面的东西。
所以我们必须得放到 package.json 里面，不然它出不来。
那么接下来，我们先不用 dev-server，看下效果：
可以看到，编译成功，页面也是灰色的。
那么我们再使用 npm run start 启用 dev-server 看看：
可以看到，http://localhost:8080/ 的页面也是 OK 的。
既然 dev-server 可以自动的去做热更新，热加载，那么我们就来试试：
比如我们将背景色从灰色设置成红色：
可以看到，当我们修改了代码，保存的时候，它是可以自动编译的。
但是，我们发现页面的颜色还是灰色，没有变，刷新也不管用：
即使我们把整个浏览器都关了，在重新打开也没用，仍然是灰色。
其实这里有个小坑，刚接触这块的很容易踩到：就是 index.html 的路径问题。
dest 目录下 bundle.js 是我们上一次编译的文件。我们把它们都删掉：
然后这时候，我们如果继续更改文件，就会发现，它仍然会一直编译：
我们一直在改颜色，它也一直在编译，没问题。但是你会发现，左上角根本就没有 dest 目录。明明都已经重新编译了，那为什么还没有 dest 目录呢？
这是因为 dev-server 实际上来说，并不会真的去把这个文件给写出来，它是把这个编译结果保存在内存里面的。
那么我们到底应该怎么样去找这个编译结果呢？
其实我们在 index.html 里面直接写：<script src="dest/bundle.js"></script> 是错的。我们这么写，它找的其实是我们之前手动编译的文件。
在 dev-server 里面，它的 bundle.js，其实就是我们在 webpack.config.js 配置里面的 output.filename 设置的文件名，注意，它是没有路径的：
也就是说，它根本就不考虑 path，只看 filename。
说的直白点，我们直接去找根目录下的 bundle.js 就好了：
也就是说，在我们 localhost:8080 这个路径下面，它是有一个 bundle.js 文件的：
可以看到，它在这是有一个文件的。当然这个文件只存在于内存当中，它不会真的在文件里面看到。
如果这时候，我们再来查找刚才设置的背景色 blue，就可以找到了：
现在每次我们再修改完文件，浏览器也是跟着变的。并且重新编译后，都是可以在这里找到的。所以这个文件是一直在变的，当然它不是一个真正的文件，它只在 dev-server 的内存中存在。
所以这个路径问题的坑，我们需要注意下。
然后，我们试下修改背景为图片，并且添加 url-loader：
然后我们会发现，即使添加了 url-loader，它仍然报错了：
报错的原因是说，我们没有配置 url-loader 导致图片解析不了。但是我们明明配置了啊？
这里需要注意一点：
热更新，指的是能更新源文件，你写的 js，css 都属于源文件。
但是，一旦你的 index.html 变了，你就得重新刷新页面。
如果是 webpack.config.js 变了，你就必须得重新启动 dev-server，因为它是在启动阶段读取的 config 文件。
然后我们关闭后，重新启动 der-server：
可以看到，图片出来了，并且是 base64。
其实这里之所以没出问题，是因为我们没有加 limit，就导致了它所有的图片都会被转换成 base64。
所以我们配置的 outputPath、publicPath，其实根本就没起作用。
那么我们配置 limit 之后，再重新启动下 dev-server。之所以需要再次重启，是因为我们的 webpack.config.js 变了。
然后就可以看到，图片没有了，因为它找的是 dest/imgs 目录下面的图片。
我们可以把这个地址给打出来看一下，到底有没有：
可以看到，确实是没有。
其实，这个问题和我们上面说的 html 问题是一样的，也是目录的问题。
那么我们删掉 dest 目录，图片就出来了。
简单来说，其实它现在根本就不是一个真实存在的文件。所以在这个时候，它并不会真的给你输出到某一个目录里面。那自然也就不会碰到这个目录的问题。它们其实都是以 localhost:8080 这个根为准的了。
所以我们现在就不用 publicPath 了，然后我们重新启动 dev-server：
所以，我们用了 dev-server 之后，我们一定要清楚：
这个并不是一个真正把文件输出出去的过程。所有这些编译的结果，都只是保存在 dev-server 它自己的内存当中。
所以，这也就决定了它没有办法去服务于一个大型的网站，因为它是全部存在内存里面的。
当然，它这么做主要是为了性能考虑，也就是为了快。因为我们只要一改文件，立马就有了。要是如果真的去往磁盘上编译，就会慢一些。
