为何咱们不用sourcemap了？hey-cli默认关闭打包配置

• 什么是source map？
• webpack目前的source map生成策略
• 为何咱们不用source map了？
• 什么是反向代理？
• 咱们如何调试前端BUG？

什么是source map？

随着代码增多，咱们须要对代码进行压缩。
代码压缩后进行调bug定位将很是困难，因而引入sourcemap记录压缩先后的位置信息记录，当产生错误时直接定位到未压缩前的位置，将大大的方便咱们调试。
----from 网络
阮一峰写的一篇文章，JavaScript Source Map 详解，你们若是感兴趣能够看一看。

其实，不少程序员有可能不是很了解。
可是没有关系，咱们这篇文章主要是关于前端开发、调试的经验分享。

webpack目前的打包策略

webpack的 devtool 属性是用来配置代码source map生成策略的。
从适用于开发环境到适用于生产环境，每一种都些微有一些不一样。
而 hey-cli 的devtool只选择开发环境的eval，与生产环境的none，这两种是webpack打包部署最快的策略，分别都是+++(super fast)的速度。

而其余的关于sourcemap的策略都被咱们无视了。
至于下面，咱们将列出咱们为何无视这些sourcemap打包策略的缘由。

为何咱们不用sourcemap了？

一、chrome自带了pretty print的功能

关于一些代码上的错误，使用chrome调试能够直接pretty代码，压缩代码通过pretty后，可读性大大增高。

二、若是build代码使用sourcemap，build速度大大下降

sourcemap附带了不少信息，若是build须要生成sourcemap，将会大大下降build的速度。

三、咱们都是使用本地代码来调试全部环境的BUG

是的，感谢反向代理的机制。
若是问题比较复杂，或者是性能类的，很难从线上的代码中调试出结果。
咱们经过修改hey-cli的反向代理配置，便可调试不一样的环境。
最后一章，咱们会详细说明。
若是你对hey-cli不是很了解，请移步前端开发大杀器hey-cli，全局支持vue react es6开发部署。
固然，若是你是使用webpack配置，包括vue-cli等脚手架生成webpack配置，均可以使用。

什么是反向代理？

这个我就不详细说明，你们能够看看nginx的一些配置便可。
阮一峰先生也写了一个初级入门：Nginx 容器教程

webpack反向代理配置

webpack代理配置: devServer.proxy

hey-cli反向代理配置

hey-cli只须要在hey.conf.js中的webpack对象下配置devServer便可，配置和devServer.proxy一致。

hey.conf.js

module.exports = {
  ...
  "webpack": {
    ...
    //define proxy, https://webpack.js.org/configuration/dev-server/#devserver-proxy
    "devServer": {
      "proxy": {
        "/api": {
          "target": "http://0.0.0.0:8080"
        }
      },
      historyApiFallback: true
    }
  }
};
复制代码

咱们如何调试前端BUG？

前面说了这么多，其实只剩下最后一步了。
先说实际操做：
以使用hey-cli为例。
平时的开发环境hey.conf.js：

devServer: {
  proxy: {
    "/api": {
      //开发环境后端
      target: "http://开发环境:8080",
      pathRewrite: { "^/api": "" }
    },
  },
  historyApiFallback: true
},
复制代码

调试正式环境

devServer: {
  proxy: {
    "/api": {
      //正式环境后端
      target: "http://正式环境:8080",
      pathRewrite: { "^/api": "" }
    },
  },
  historyApiFallback: true
},
复制代码

重启hey-cli，访问开发环境，使用正式环境的后端。

调试完成，checkouthey.conf.js，提交hotfix。

注意

咱们的前端团队始终保持一个作法：全部环境的前端代码是如出一辙的，而且不推荐使用js来判断不一样的环境。 至于为何这样子作，相信你们均可以理解。 关键问题是，如何完成这样的一个设定？ 目前咱们的作法是，gateway提供一个/envs的接口，每一个环境的不一样配置经过接口统一获取。 若是你们感兴趣的话，能够继续讨论，看看有没有什么更好的施行方案。