- 什么是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了？
1、chrome自带了pretty print的功能
关于一些代码上的错误，使用chrome调试可以直接pretty代码，压缩代码经过pretty后，可读性大大增高。
2、如果build代码使用sourcemap，build速度大大降低
sourcemap附带了很多信息，如果build需要生成sourcemap，将会大大降低build的速度。
3、我们都是使用本地代码来调试所有环境的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的接口，每个环境的不同配置通过接口统一获取。
如果大家感兴趣的话，可以继续讨论，看看有没有什么更好的施行方案。
