魔方是轉轉內部的一個可視化搭建平臺，用于快速搭建一個活動頁面。本次主要分享下在做環境隔離時遇到的一些問題以及解決辦法。

魔方基礎依賴介紹

• A提供了本地運行組件的能力以及組件需要的所有第三方依賴
• B提供了配置區的一些常用表單項，如跳轉配置、展示終端配置等
• C提供了預覽區的一些常用能力，如跳轉、埋點上報等
• A依賴B和C，B和C又依賴A

一個魔方組件，通常只需要依賴A即可，因為在安裝A的時候會自動將B & C的內容打包生成到A中。

"dependencies": {
  "A": "^1.0.0"
}

為什么要做環境隔離

之前，我們在編譯某個基礎依賴（例如 B）時：

• 會發布一個正式包（B@1.0.1）
• 并將測試服務器上專門存放公共依賴的文件下的node_modules刪除，然后執行npm install重新安裝依賴
• 在安裝中會使用我們最新發布的B@1.0.1。（此處實際是在一個臨時文件夾中操作，然后安裝后再復制出來的，可以減少測試環境的不可用時間）

舉一個常見的場景來說明下這種模式的問題——小明在開發B，小紅在開發C，兩人都在測試環境進行了編譯，導致發出去了兩個正式包B@1.0.1 & C@1.0.1 。那么此時，如果小明開發測試完了，想要上個線，那么在服務器上執行到npm i的 時候，就會把小紅還未測試完成的包C@1.0.1給安裝到線上環境去。（其實在測試服務器上兩個人的代碼也是混合在一起的，不過畢竟是測試環境，影響較小）

從這個場景分析，可以發現有兩個主要的問題：

1. 測試環境發布正式包，導致線上無法區分
2. npm install正常只會安裝正式包，不會安裝beta包

設計思路

針對上述的兩個問題，對應的解決辦法就是：

1. 測試環境發beta包，線上發正式包
2. 使用npm install package@version(-beta) 替換npm install

第一點就不說了，大致就是先npm view packageName versions獲取包的所有版本，然后根據環境去獲取最新的正式包版本或者是最新的beta版本，然后修改版本號再發包。

第二點，在更新依賴的時候，通過指定版本號的形式去安裝我們最新發布的包。只不過在線上環境中，安裝的是正式包，測試環境中安裝的beta包。

看起來一切是那么的美好，但現實并不總是一帆風順......

問題復現&解決

初始化一個文件temp，并執行npm i先將所有依賴裝一遍。

此時temp/node_modules下的情況為（此處只舉例A和B，C與B情況相同，不再重復）

A: "A@1.0.0"  A/node_modules下：無其他依賴

B: "B@1.0.0"  B/node_modules下：無其他依賴

接下來，執行 npm i B@1.0.0-beta.1去單獨更新B。

執行結果：

A: "A@1.0.0"  A/node_modules下：B@1.0.0

B: "B@1.0.0-beta.1"  B/node_modules下：無其他依賴

根據npm包安裝的機制，默認情況下是不會使用beta包的，A依賴的B: "^1.0.0"需要使用穩定的版本，所以beta版本被放在最外層，而將之前的B@1.0.0放在了A/node_modules下。

魔方的基礎依賴在使用前會在 A下執行一個externals命令（postinstall：npm run externals）將B的內容打成dist放在A目錄下。但是node_modules依賴的查找順序是先從當前文件目錄下查找的，所以生成dist文件時使用的將會是A/node_modules/下的B@1.0.0，而不是最外層的B@1.0.0-beta.1

所以，我需要手動刪除A/node_modules/B@1.0.0，再去執行externals命令。

那接下來我們再試試在此基礎上更新A，npm i A@1.0.0-beta.1。

結果就是出現了更多冗余的依賴。。。

A: "A@1.0.0-beta.1"  A/node_modules下：B@1.0.0、A@1.0.0

B: "B@1.0.0-beta.1"  B/node_modules下：B@1.0.0、A@1.0.0

原因跟之前一樣，我們安裝的beta版本的A不符合B所依賴的A: "^1.0.0"，就導致B下的node_modules中又多了一個A@1.0.0，然后這個A@1.0.0的又依賴一個穩定版本的B，所以在同級目錄下還會再多一個B@1.0.0

同樣的，我們仍需要先手動的去刪除這些冗余的、不符合我們要求的依賴。

綜上，為了確保我們項目中使用的都是我們剛發布的beta包，我們需要在每一次更新依賴時都執行一下這兩條命令去清除冗余的依賴，然后再去執行打包命令。

rm -rf ./node_modules/A/node_modules/
rm -rf ./node_modules/B/node_modules/
rm -rf ./node_modules/C/node_modules/

cd node_modules/A
npm run externals

然而，到這一步還沒完事，我將代碼部署到測試服務器上后，經常出現依賴沒有安裝完成或安裝完沒有生成dist文件的情況，總是執行到一半就“中斷”了。但是我在本地測試的時候卻不會出現這種問題。

經過一步一步的排查，最終將問題定位到了這一行代碼

await shelljs.shellExec()

查看shelljs.shellExec方法：

exports.shellExec = function (command, options = {}) {
  return new Promise((resolve, reject) => {
    Object.assign(options, {timeout: 300000});
    shell.exec(command, options, () => {});
  });
};

經常中斷，難道是過了超時時間？我試著將超時時間從5min改到10min，部署至測試服務器，再次更新依賴，一切正常了......（不得不吐槽這個測試服務器的性能甚至不如我的Mac）

再一看編譯時間，耗時>10min，!真棒。(取反??)

優化

如此低效率的更新顯然不能讓人滿意，而且由于魔方自身的原因，當編譯基礎依賴時，其他人是不能再部署其他魔方服務的，這就會阻塞其他人的流程，對開發人員的體驗是十分差的。

「首先就是先分析問題找出原因：」

1. 很容易想到的，當安裝beta版本的依賴時，總是會額外產生很多冗余的穩定版本的依賴。
2. 安裝依賴耗時么？耗時，但是至于這么耗時么？不至于。耗時中的大頭另有其因，其實就是A中的externals命令，打包，這個是比較耗費時間的通常需要1-2分鐘。

所以在一定程度上是問題1導致了問題2——安裝了冗余的依賴，其中冗余的A會自動執行externals 命令導致耗時過久。

「所以我們首先需要解決的就是避免安裝冗余的依賴：」

A需要依賴B，是因為需要將B的內容打包生成到A下使用。

B需要依賴A只是因為本地開發時方便調試。

如果去掉B的依賴項，那就可以在安裝B@beta時避免額外安裝A。但是，本地開發B的場景還是很多的，因此需要想個辦法盡可能的減少由此帶來的對開發體驗的影響。

于是我在腳本中加入了一個自動檢查并安裝依賴的命令depcheck。

// dev之前先檢查A：
// list可以列出當前工程下的A情況以及版本
// 如果沒有會返回一個假值并走到npm i命令去安裝A
"predev": "npm list A || npm i --no-save A"

這樣，在安裝B@beta的時候就不會額外安裝A也不會額外執行externals命令了。

那么在安裝A@beta的時候呢？還是會額外安裝冗余的B然后自動執行externals，然后刪除冗余的B，再手動執行一次externals。

「接下來需要針對A再次進行優化：」

由于A是強依賴B的所以不能去掉依賴項，冗余的B肯定是避免不了的，不過這又有什么關系呢，安裝再刪除一共也影響不了幾秒鐘。

但重點是A中有這樣一個腳本命令：postinstall：npm run externals該命令是為了在開發時安裝依賴等場景可以自動執行externals以減少操作次數&降低學習成本。

這就會導致第一次執行externals的時候實際使用的是冗余的穩定版本B，而非我們需要的最外層的B@beta，所以還需要刪掉冗余依賴然后額外執行一次externals，這才是最耗時的部分。

“要是在npm i的時候可以不執行postinstall就好了”，帶著這個期許，我找到了一個好用的參數——--ignore-scripts（忽略依賴中的腳本命令，不去執行任何腳本）

npm i A@beta --ignore-scripts

這樣一來，在安裝A的時候，也不會額外執行externals命令了！

「優化前后編譯耗時對比：」

總結

以上，就是在對魔方基礎依賴環境隔離改造的思路和問題的解決：

1. 通過發布beta版本的包來區分測試環境與線上環境
2. 但是帶來了編譯速度嚴重下降的問題
3. 通過去掉B中的依賴項來避免安裝冗余的依賴
4. 針對A，在npm i的使用加入--ignore-scripts命令來避免額外執行打包命令externals