如何使用webpack配置一个开发环境

仅仅是开发环境玩玩哦~~~~~

首先来看看source map,当 webpack 打包源代码时,可能会很难追踪到错误和警告在源代码中的原始位置,比如a.js、b.js、c.js,我们一个build之后,就变成了一个bundle,这个时候如果报错了,我们是如何知道这个错误具体在哪一个js呢?

source-map,实际上会显著的提高我们调试的速度,尤其是在有脚本文件报错的时候,当然,source-map有很多的配置项,我们常见的就是“source-map”,这些不同的配置项,我们要根据生产环境或者开发环境来配置,因为这在打包构建的时候,会影响速度。

下面是官网的一个配置列表,我们可以看到一些可选项,而且不同的环境支持,还有构建的速度

我们先看看开发环境咯。

其实只需要在我们的webpack配置文件中添加一行devtool就可以了,然后npm run build。哎嘿,好像没什么反应啊,和其他地方一样啊!

那你打开这个文件,在控制台的sources中看看,你可以试试把这个删掉,然后再加上看看区别,是不是会发现,当你不加这个的时候,是只有一个压缩过的光秃秃的文件的?这种情况你怎么打断点?但是加上之后,就会有一个webpack的选项,当我们点开之后就会发现我们的源文件。

但是好像每一次我们代码改动之后,都要npm run build啊,这样是不是太麻烦了,我们发现一般的脚手架,代码改动保存之后就会自动编译,这是什么鬼哦~~~

webpack 中有几个不同的选项,可以帮助你在代码发生变化后自动编译代码:

webpack's Watch Mode
webpack-dev-server
webpack-dev-middleware

一般情况下,我们都是选择webpack-dev-server, 我们先试试官网的观察者模式:

首先在package.json中添加启动观察者模式的脚本

    "scripts": {
      "test": "echo \"Error: no test specified\" && exit 1",
+     "watch": "webpack --watch",
      "build": "webpack"
    },

现在修改文件,就可以看到webpack编译文件了,唯一的缺点是,为了看到修改后的实际效果,你需要刷新浏览器: 启动npm run watch,然后就可以看到已经在监听我们的命令面板了

懵里懵逼的按照官网操作了一通,一顿操作猛如虎,实际结果如CC打枪一样看不懂,,我们还是看看webpack-dev-server吧:

webpack-dev-server实际上提供给我们一个开发服务器,或许你也猜到了,就是我们最常见的localhost:8080什么的,然后修改文件就会自动刷新文件

npm install --save-dev webpack-dev-server

配置启动服务的脚本

  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1",
    "watch": "webpack --watch",
    "build": "webpack",
    "dev": "webpack-dev-server --open"//  开发环境启动脚本
  },

然后在我们的webpack文件中配置一下该服务访问的文件,我们制定dist

然后我们运行npm run dev来看看

是不是神奇的通过命令行可以发现,我们之前说的三个要点所在:一个脚本启动,一个端口监听,一个监听的文件目录

现在我们修改文件的时候,就会发现浏览器自动刷新!哇哦~~~~~这也太爽了吧,没事干自己搞一个专门用来写例子,再也不用通过刷新浏览器来查看demo效果了,一次没关系,但是时间久了可想而知节约的时间。

我们再来看看vue-cli或者是react脚手架的package.json来找点事情做,哎嘿嘿嘿~~~~

这是vue的

再来看看react的

好像vue-cli的脚手架很淘气啊!竟然两个还不一样,我们看看这个webpack-dev-middleware

webpack-dev-middleware 是一个容器(wrapper),它可以把 webpack 处理后的文件传递给一个服务器(server),实际上,官网的解释来说,我们前一个webpack-dev-server内部也是用了这个容器。之所以有的项目把这个单独拿出来使用,其实是为了更多的自定义设置来做更多事情,虽然不知道能干嘛,但我们还是看看官网的例子,然后结合vue-cli来研究研究

先来看看官网的例子,很符合它本身的定义,一个服务【node】,而它只充当容器,

npm install --save-dev koa webpack-dev-middleware

首先,我们修改一下配置文件, publicPath 也会在服务器脚本用到

其次我们用koa来创建一个node server.js,监听我们的9001端口或者你看的顺眼的端口,似乎这里我们就懂了,webpack-dev-server是把服务器配置好了,少了很多可操作空间,而webpack-dev-middleware是把服务器的操作交给了我们,这样我们根据自己的需要来配置,官网是用了express,我偏偏喜欢koa啊,我们试试koa啊!

三行代码起一个koa服务~~~

var Koa = require('koa')
const app = new Koa()

app.listen(9001)
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1",
    "watch": "webpack --watch",
    "build": "webpack",
    "dev": "webpack-dev-server --open",
    "koa-server": "node koa-server.js" // 添加启动node服务的脚本
  },

这个时候我们运行一下npm run koa-server 发现已经有一个服务起来了,但是好像什么东西都没有,是因为我们的服务光秃秃的和CC的头一样啊!!!只有三根头发怎么会有东西,这个时候就是前面说的publish 的作用了,我们把webpack东西引入来做一点事情。

等我一下,我的koa失败了,装逼出了一点叉子,正在解决。

嗯哼,继续更新。

事实上,大多数 webpack 用户用过的 webpack-dev-server 就是一个 express+webpack-dev-middleware 的实现。二者的区别仅在于 webpack-dev-server 是封装好的,除了 webpack.config 和命令行参数之外,你很难去做定制型开发,所以它是适合纯前端项目的辅助工具。而 webpack-dev-middleware 是中间件,你可以编写自己的后端服务然后把它整合进来。

这么说来,前面的装逼就显得很翻车了,因为我们选择的koa并不能直接使用啊,我又安装了一下express,试了一下,果然不负众望!完全可以,那我们就想使用koa怎么办啊!好炸鸡!关键问题在于 webpack-dev-middleware 是 express 标准的中间件,并不能直接用于 Koa。

先来看看基于express的中间件

expressApp.use((req, res, next) => {
  if (nextNeeded) {
    // do what you want
    // until you need down-stream middleware(s)
    next();
  } else {  
    // anything else, e.g. sending response
  }
});

再来看看基于koa的中间件

server.use((context, next) => Promise.resolve(() => doSomething()
  .then(() => {/* before next middleware */})
  .then(() => next())
  .then(() => {/* ... and more */})
  .then(() => {/* after down-stream middleware(s) */})
));

可以明显的看到,koa的中间件中res并不是一个可以执行的函数,这就是为什么我们在用koa的过程中会报错的原因。

 

webpack-dev-middleware 需要两个参数:

  • compiler:可以通过 webpack(webpackConfig) 得到
  • options:补充 webpack-dev-middleware 需要的特定选项,其中 publicPath 是必须的,并且其值应该等于 webpackConfig.output.publicPath
    我们使用express的时候根据自己环境的全局变量全局配置就好了。koa的话~~~我先去继续研究一下了

“如何使用webpack配置一个开发环境”的一个回复

发表评论

电子邮件地址不会被公开。 必填项已用*标注