爲何咱們不用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的接口，每一個環境的不一樣配置經過接口統一獲取。 若是你們感興趣的話，能夠繼續討論，看看有沒有什麼更好的施行方案。