大廠技術(shù)??高級前端??Node進(jìn)階

點擊上方?程序員成長指北，關(guān)注公眾號

回復(fù)1，加入高級Node交流群

自 2018 年 5 月 Firefox 60 發(fā)布后，所有主瀏覽器均默認(rèn)支持 ES modules。借助 ES modules 的能力，代碼可以實現(xiàn)無需構(gòu)建直接運行。

隨著 Vite 和 Snowpack 等基于 ES modules 的構(gòu)建工具的產(chǎn)生，前端隨即掀起了 ES modules 新一輪熱潮。

天下武功，無招不破，唯快不破 ?- 李小龍

Vite、Snowpack 等基于 ES modules 的構(gòu)建工具帶來了開發(fā)的極致體驗，相比傳統(tǒng)的構(gòu)建工具，這些新型的構(gòu)建工具或多或少地帶來了以下優(yōu)勢：

• 由于無需打包的特性，服務(wù)器冷啟動時間超快

借助 ES modules 的能力，模塊化交給瀏覽器處理（雖然目前的階段存在一個預(yù)編譯的過程）。傳統(tǒng)構(gòu)建器需要打包依賴和源碼，才能構(gòu)建整個應(yīng)用，并提供服務(wù)。

• 項目大小不再成為限制項目熱更新速度的因素

傳統(tǒng)構(gòu)建器在代碼更改時，需要重新構(gòu)建并載入頁面，這樣帶來的的結(jié)果是：隨著項目體積增長，構(gòu)建耗時越長。基于 ES modules 的構(gòu)建器只進(jìn)行單文件編譯，單文件更新，時間復(fù)雜度保持 O(1).

Vite 得益于原生 ES modules 的能力，大幅提升了開發(fā)時體驗。相信未來，隨著社區(qū)生態(tài)（CDN 服務(wù)、Deno）、ESM 相關(guān)標(biāo)準(zhǔn)（import-maps、import.meta）的逐步完善，以及越來越多的技術(shù)方案解決 ES modules 在瀏覽器端的相關(guān)難題（依賴瀑布，資源碎片化），前端會開啟一個無構(gòu)建的新篇章。

同時在微前端領(lǐng)域，腳本資源的打包規(guī)范向來是百花齊放（比如 singleSPA 默認(rèn)支持 SystemJs 規(guī)范，icestark 默認(rèn)支持 UMD 規(guī)范）。未來腳本資源的打包規(guī)范必定是趨于統(tǒng)一的 ES modules 規(guī)范。正是基于這兩個原因，微前端支持 ES modules 應(yīng)用的加載就成了用戶強(qiáng)訴求。

Vite 會默認(rèn)打包出符合標(biāo)準(zhǔn)的 ES modules 的腳本資源。ES modules 資源的加載方式如下：

<script src="index.js" type="module">script>

然而，在 icestark 中需要依賴微應(yīng)用導(dǎo)出 生命周期函數(shù) 來渲染微應(yīng)用。使用 js += `\nimport "${id}?html-proxy&index=${inlineModuleIndex}.js"` shouldRemove = true }}...

Vite 默認(rèn)使用 index.html 作為入口，在解析 index.html 的過程中，會生成一個虛擬的入口文件，將腳本資源通過 import 注入進(jìn)來，也就是最終的入口文件實際上類似于下面的代碼：

import './src/main.ts';import 'polyfill';

面對這個場景，我們想到了兩種解決方案：

• 借助 Vite Lib 模式，修改應(yīng)用入口：

// vite.config.tsexport default defineConfig({  ...??build:?{????lib:?{??????entry:?'./src/main.ts',??????formats:?['es'],??????fileName:?'index'????},????rollupOptions:?{??????preserveEntrySignatures:?'exports-only'????}??},})

這種方式有個明顯的問題是：Vite 以 Lib 模式構(gòu)建出的應(yīng)用，其產(chǎn)物并不是一個完整的前端應(yīng)用（缺少 index.html），無法滿足獨立運行的條件。

• 通過插件修改 Vite 的這一默認(rèn)行為

通過 vite-plugin-index-html 插件，結(jié)合 Vite 的解析能力，將入口修改為靜態(tài)資源的入口。

import htmlPlugin from 'vite-plugin-index-html';
// vite.config.tsexport default defineConfig({  plugins: [vue(), htmlPlugin({    input: './src/main.ts'  })]})

同時，icestark 也支持 ice.js Vite 模式快速接入。安裝或升級 build-plugin-icestark 插件，在微應(yīng)用 build.json 中配置：

{+  "vite": true,  "plugins": [    ["build-plugin-icestark", {      "type": "child",    }]  ]}

即可得到正確導(dǎo)出生命周期函數(shù)的微應(yīng)用。詳細(xì)用法可參見 使用 ice.js Vite 模式。

為了解決時間上，長尾應(yīng)用升級帶來的效率問題，微前端通常是大型架構(gòu)升級所選擇的中間態(tài)（或終態(tài)）方案。因此在設(shè)計加載 ES modules 方案時，需要保持這一基準(zhǔn)原則。

框架應(yīng)用可以保持現(xiàn)有的構(gòu)建方式不變（仍然可以使用 webpack 等非原生 ES modules 構(gòu)建工具），亦無需對框架應(yīng)用做任何構(gòu)建上的改造。

因此，基本可以無痛嘗試 Vite 所帶來的快感，腳踏實地地，一點點地靠近遠(yuǎn)方。

通過對 ES modules 原理的探尋，可以知道 ES modules 只執(zhí)行一次。換成實際例子，也就是說當(dāng)?shù)诙螆?zhí)行相同的加載腳本時：

// icestark 第二次執(zhí)行加載腳本const { mount, unmout } = import(esModule);

瀏覽器不會重復(fù)執(zhí)行 Construction -> Instantiation -> Evaluation 的流程，而是直接返回上次模塊執(zhí)行的結(jié)果。這會導(dǎo)致一些副作用的操作（比如在 Module Conext ?下插入樣式資源，腳本資源的行為，這給我們的微應(yīng)用二次加載帶來了額外的問題），同時也帶來了極快的二次加載效果。

建立在原生 ES modules 規(guī)范下的應(yīng)用不會在短時間內(nèi)快速鋪開，很多 To C，To 商戶的業(yè)務(wù)對瀏覽器的版本仍有限制。但是，icestark 在 2.x 快一年多的發(fā)展以來，仍希望覆蓋到多樣的開發(fā)場景，提供便捷、快速地業(yè)務(wù)升級。在支持傳統(tǒng) JS bundle、UMD 規(guī)范，本文分享了 icestark 在接入 ES modules 規(guī)范微應(yīng)用的一些嘗試，希望能給開發(fā)者帶來一些新的選擇和啟發(fā)。

引用

• icestark - 面向大型系統(tǒng)的微前端解決方案

• proposal-dynamic-import

• Vite - Next Generation Frontend Tooling

• ES modules: A cartoon deep-dive

• What Happens When a Module Is Imported Twice?

我組建了一個氛圍特別好的 Node.js 社群，里面有很多 Node.js小伙伴，如果你對Node.js學(xué)習(xí)感興趣的話（后續(xù)有計劃也可以），我們可以一起進(jìn)行Node.js相關(guān)的交流、學(xué)習(xí)、共建。下方加 考拉 好友回復(fù)「Node」即可。

???“分享、點贊、在看” 支持一波??