您好,登錄后才能下訂單哦!
js中ESM規(guī)范的示例分析,相信很多沒有經(jīng)驗的人對此束手無策,為此本文總結(jié)了問題出現(xiàn)的原因和解決方法,通過這篇文章希望你能解決這個問題。
前端發(fā)展到如今,社區(qū)生態(tài)已經(jīng)非常豐富。
在無數(shù)開源大神的努力下,很多前端開發(fā)的痛點(比如「靜態(tài)類型檢查」、「瀏覽器兼容性」)早已有了事實上的標準解決方案(比如TS、babel)。
然而,在這繁榮之下,有一個日常開發(fā)不易感知的問題:
模塊化規(guī)范的混亂
你可曾遇到過莫名其妙的bug,在多方搜資源,反復(fù)驗證,耗費數(shù)個小時終于發(fā)現(xiàn):
原來是某個包導(dǎo)出的是CJS,而項目使用ESM導(dǎo)致。
比如這個例子:記一次打包壓縮報錯[1]
如果你覺得這是個很容易發(fā)現(xiàn)的問題,再考慮結(jié)合上node_modules的層層依賴呢?
這個問題,揭開了模塊化規(guī)范間斗爭與博弈的冰山一角。
作為現(xiàn)代前端工程化的基石,模塊化規(guī)范有太多值得深究的內(nèi)容。
我會花幾篇文章來講解模塊化規(guī)范。本文是第一篇,會圍繞模塊化規(guī)范的演進展開。
如果問十年前的前端最頭疼的是什么?一定是瀏覽器兼容性。
隨著babel等編譯工具出現(xiàn),兼容性逐漸被工程化方案解決(ES6+編譯為ES5)。
不僅是「兼容性」問題,DSL(如JSX、VUE的模版語法)、代碼壓縮、代碼靜態(tài)檢查(TS)等日常開發(fā)的剛需都能在工程化方案中找到解決辦法。
如果將當(dāng)今繁榮的前端工程化生態(tài)比喻為一座大廈,那大廈的地基一定是「模塊化規(guī)范」。
現(xiàn)代JS代碼都是基于「模塊化規(guī)范」組織起來,讓我們從下往上來看看這座大廈:
規(guī)范的實現(xiàn)依賴于宿主環(huán)境,比如瀏覽器環(huán)境實現(xiàn)了EcmaScript Module(后文簡稱ESM)規(guī)范。
Node v12之前支持CommonJS(后文簡稱CJS)規(guī)范,12之后同時支持CJS與ESM。
在「宿主環(huán)境」之上,是基于模塊化規(guī)范實現(xiàn)的「工具集」,比如webpack、vite、VScode生態(tài)。
再往上,基于「工具集」提供的API,可以實現(xiàn)各種工程化工具。比如:
webpack loader
VScode plugin
babel plugin
再往上,就是開發(fā)者自己編寫的業(yè)務(wù)代碼。
開發(fā)者只需要在工具集中配置好工具,就能為業(yè)務(wù)代碼提供服務(wù)。比如:
在VScode(工具集)中配置eslint(工具),就能在開發(fā)時獲得相應(yīng)提示
在webpack(工具集)中配置babel loader(工具),就能在開發(fā)時使用ES6+語法
可見,理想狀態(tài)下,在開發(fā)者視角是不需要關(guān)注底層的「模塊化規(guī)范」實現(xiàn)的。
然而,事物是動態(tài)發(fā)展的,模塊化規(guī)范也不是一蹴而就的,讓我們回到09年。
美國程序員「Ryan Dahl」創(chuàng)造了node.js項目,將JS用于服務(wù)端開發(fā)。
node.js使用CJS[2]標準作為模塊化規(guī)范。
有了服務(wù)端模塊規(guī)范(CJS),很自然的,JS開發(fā)者們想為客戶端(主要是瀏覽器)提供一種模塊化規(guī)范。
然而CJS是為服務(wù)端設(shè)計的。
在服務(wù)端,IO操作通常能迅速完成,所以CJS規(guī)范定義的:
模塊加載 --> 模塊解析 --> 模塊執(zhí)行
這個流程是作為一個整體同步執(zhí)行的。
然而在瀏覽器環(huán)境,「模塊加載」(即數(shù)據(jù)請求)通常很耗時。有人曾作出一個形象的比喻:
如果一個CPU周期花費1秒完成,那么文件的網(wǎng)絡(luò)請求需要花費4年。
顯然瀏覽器端需要一種「支持異步」的模塊化規(guī)范。
AMD(Asynchronous Module Definition 異步模塊定義)規(guī)范,就是這樣需求背景下的產(chǎn)物。
然而這些社區(qū)提出的規(guī)范終究只是為了解決一時的需求,隨著歷史的發(fā)展,新的模塊化規(guī)范不斷涌入、消亡。
直到ESM規(guī)范被提出。
ESM規(guī)范是ES標準的模塊化規(guī)范,他的早期討論可以追溯到2009年。
你可以在這里看到ESM規(guī)范的歷史es-module-history[3]
ESM將模塊規(guī)范分為三個階段:
模塊加載 --> 模塊實例化 --> 模塊執(zhí)行
其中「模塊加載」由宿主環(huán)境提供的loader完成(比如在瀏覽器環(huán)境,loader的行為由HTML規(guī)范[4]定義)。
「模塊實例化」與「模塊執(zhí)行」由ESM規(guī)范定義執(zhí)行流程。
區(qū)別于CJS規(guī)范的同步執(zhí)行,ESM規(guī)范將流程拆解為3個獨立階段。
「模塊加載」同步、異步與否由宿主環(huán)境決定。
支持不同宿主環(huán)境,抹平多端差異、能力比其他規(guī)范都強大(后文會介紹)、再加上血統(tǒng)純正(ES官方提出),
使得ESM規(guī)范一統(tǒng)前端「看似」指日可待。
然而,此時社區(qū)已經(jīng)有大量基于CJS規(guī)范產(chǎn)出的開源包、組件,他們無法立刻切換到ESM規(guī)范。
所以,JS生態(tài)的現(xiàn)狀是:會處于、并將長期處于CJS規(guī)范的庫與ESM規(guī)范的庫共存的狀態(tài)。
但是最終,ESM規(guī)范一定會成為主導(dǎo),畢竟他的優(yōu)點太多(同樣,后文會介紹)。
當(dāng)前模塊化規(guī)范的混亂,對開源大佬們來說,就是機會。
為了讓開發(fā)者將更多精力放在業(yè)務(wù),而不是模塊規(guī)范的適配上。
很多開源「工具集」都試圖抹平模塊化差異,比如:
在babel中使用babel-plugin-transform-commonjs可以將CJS規(guī)范的代碼轉(zhuǎn)換為ESM規(guī)范
為了一刀切解決當(dāng)前ESM、CJS、瀏覽器script標簽導(dǎo)入這3種規(guī)范互相不兼容的情況,提出了兼容三者格式的UMD(Universal Module Definition)規(guī)范
一些「工具集」利用模塊化規(guī)范的不同與其他競品形成差異化競爭,比如:
browserify這款打包工具的賣點是:使用CJS規(guī)范打包,使一份代碼同時在Node環(huán)境與瀏覽器環(huán)境(打包后)執(zhí)行。
其中,在瀏覽器環(huán)境中,Node的一些核心庫(如events、stream、path...)會被打包成瀏覽器支持的版本。
Vite在DEV環(huán)境使用ESM規(guī)范構(gòu)建模塊間的依賴關(guān)系。
依賴于大部分現(xiàn)代瀏覽器原生支持ESM規(guī)范,省去了打包的過程,使其編譯速度大大提升。
rollup原生對ESM提供更多支持。
嚴格支持ESM規(guī)范,并提供更好的靜態(tài)分析,使rollup一度提供性能更優(yōu)異的treeShaking能力。
成為更多庫打包工具的首選。
與webpack這樣的的大而全方案形成差異競爭。
可以看到,由于底層宿主環(huán)境對模塊化規(guī)范支持的割裂,需要上層工具集來抹平模塊規(guī)范的差異。
設(shè)想一個同時使用了webpack、babel、TS的項目。
這3個工具集都對多種模塊規(guī)范有兼容處理。比如:
單獨使用babel時,對于如下代碼:
import a from 'lib'; console.log(a);
會被babel編譯為:
"use strict"; var _lib = _interopRequireDefault(require("lib")); function _interopRequireDefault(obj) { return obj && obj.__esModule ? obj : { default: obj }; } console.log(_lib.default);
ESM的「默認導(dǎo)出」會被編譯為包含default屬性的對象。
你可以打開babel playground[5]試試
當(dāng)多個「工具集」在同一個項目中,為了各自目的做著同一件事(抹平模塊化規(guī)范差異),
一旦工具鏈中某個插件配置有一絲絲不符合預(yù)期,或者引入了一個不符合預(yù)期的包,那么艱難的debug就此開始了......
曙光即使當(dāng)前有諸多不便,歷史的進程是無法阻止的,那些被歷史巨輪甩下并碾碎的模塊化規(guī)范,會逐漸消失在開發(fā)者的視野中。
看完上述內(nèi)容,你們掌握js中ESM規(guī)范的示例分析的方法了嗎?如果還想學(xué)到更多技能或想了解更多相關(guān)內(nèi)容,歡迎關(guān)注億速云行業(yè)資訊頻道,感謝各位的閱讀!
免責(zé)聲明:本站發(fā)布的內(nèi)容(圖片、視頻和文字)以原創(chuàng)、轉(zhuǎn)載和分享為主,文章觀點不代表本網(wǎng)站立場,如果涉及侵權(quán)請聯(lián)系站長郵箱:is@yisu.com進行舉報,并提供相關(guān)證據(jù),一經(jīng)查實,將立刻刪除涉嫌侵權(quán)內(nèi)容。