Redmi Pad評(píng)測(cè)：紅米充滿野心的一次嘗試
從Note系列到K系列，從藍(lán)牙耳機(jī)到筆記本電腦，紅米不知不覺之間也已經(jīng)形成了自己頗有競爭力的產(chǎn)品體系，在中端和次旗艦市場上甚至要比小米新機(jī)的表現(xiàn)來得更好，正所謂“大丈夫生居
ECMAScript Module（ESM）逐漸成為現(xiàn)代 JavaScript 開發(fā)中的公認(rèn)行業(yè)標(biāo)準(zhǔn)。自從 ESM 被引入到 Node.js 以來，其異步加載特性和模塊解析邏輯受到了廣泛歡迎。
然而，由于歷史原因，許多現(xiàn)有代碼庫和第三方庫仍然依賴于 CommonJS（CJS）模塊系統(tǒng)。由于 ESM 的設(shè)計(jì)是異步加載的，這兩種模塊化方案一直無法共存，這成為了許多開發(fā)者的一個(gè)主要痛點(diǎn)。
最近，開發(fā)者 joyeecheung 提交了一個(gè)重要的 Pull Request 來解決這個(gè)問題。
在 JavaScript 的世界里，模塊化是構(gòu)建大型應(yīng)用程序的基礎(chǔ)。模塊化幫助開發(fā)者管理代碼而不影響全局命名空間，使得分離功能、重用代碼和管理依賴變得更加容易。在 Node.js 和瀏覽器環(huán)境中，有兩種主流的模塊系統(tǒng)：CommonJS（CJS）和 ECMAScript Module（ESM）。
CommonJS 是 Node.js 原生支持的模塊系統(tǒng)，最初是為了滿足服務(wù)器端的模塊化需求。CJS 使用 require 函數(shù)來加載模塊，并使用 module.exports 或 exports 對(duì)象來暴露代碼。CJS 模塊的特點(diǎn)是同步加載，這意味著模塊加載完成后，代碼會(huì)立即執(zhí)行：
// math.jsfunction add(x, y) { return x + y;}module.exports = { add };// app.jsconst math = require('./math.js');console.log(math.add(0, 17)); // 輸出 17在服務(wù)器環(huán)境中，同步加載通常不是問題，因?yàn)榇蠖鄶?shù)文件都是本地的。然而，在瀏覽器環(huán)境中，同步加載會(huì)導(dǎo)致性能問題，因?yàn)樗鼤?huì)阻塞瀏覽器的事件循環(huán)，直到腳本完全下載和解析完畢。
ESM 是現(xiàn)代 JavaScript 的官方標(biāo)準(zhǔn)模塊系統(tǒng)，并且得到了最新版本瀏覽器的原生支持。與 CommonJS 不同，ESM 被設(shè)計(jì)為靜態(tài)的，這意味著不能在運(yùn)行時(shí)動(dòng)態(tài)加載或創(chuàng)建模塊。ESM 使用 import 和 export 語句進(jìn)行模塊的導(dǎo)入和導(dǎo)出，支持異步加載：
// math.jsexport function add(x, y) { return x + y;}// app.jsimport { add } from './math.js';console.log(add(0, 17)); // 輸出 17ESM 的設(shè)計(jì)允許瀏覽器優(yōu)化加載和解析過程，例如通過 HTTP/2 高效并行加載和通過樹搖優(yōu)化去除未使用的代碼，從而提升性能和效率。然而，在 Node.js 中，ESM 的異步特性與大量現(xiàn)有的 CommonJS 模塊之間存在不兼容的問題。
在 Node.js 中啟用 ESM 目前需要更復(fù)雜的方法，因?yàn)槟J(rèn)情況下，.js 文件擴(kuò)展名與 CommonJS 模塊關(guān)聯(lián)。為了解決這個(gè)問題，Node.js 允許使用 .mjs 文件擴(kuò)展名或在 package.json 中顯式指定 "type": "module" 屬性來指示 ESM 模塊。
雖然 Node.js 支持導(dǎo)入 CommonJS 模塊，但卻無法通過 require 加載 ESM 模塊。這種因 ERR_REQUIRE_ESM 錯(cuò)誤導(dǎo)致的挫敗感困擾了許多人，并且可能是 Node.js 生態(tài)系統(tǒng)內(nèi)時(shí)間浪費(fèi)的主要原因之一。
如果包作者希望確保 CJS 和 ESM 用戶都能使用他們的包，他們要么必須繼續(xù)發(fā)布 CJS 模塊，要么發(fā)布 CJS 和 ESM 版本的雙模塊（這可能會(huì)引發(fā)一些問題，但現(xiàn)在已經(jīng)是一種非常普遍的做法）。
同時(shí)，許多轉(zhuǎn)譯器（例如 TypeScript 編譯器）仍然配置為生成 CJS 代碼作為最終輸出。這些轉(zhuǎn)譯器的用戶使用 ESM 語法編寫代碼，但他們可能不知道他們的代碼最終由 Node.js 作為 CJS 運(yùn)行。當(dāng)他們的代碼使用真正的 ESM 第三方模塊（無法被 require）時(shí)，他們會(huì)看到 ERR_REQUIRE_ESM。這會(huì)非常令人困惑，因?yàn)樗麄兛赡苷J(rèn)為他們的代碼是作為真正的 ESM 運(yùn)行的。
自然，人們可能會(huì)問：為什么 require() 不支持加載 ESM？
長時(shí)間以來，Node.js 項(xiàng)目的回答一直是這樣的：
使用 require 加載 ES 模塊是不支持的，因?yàn)?ES 模塊是異步執(zhí)行的。
但是，這種情況中的文檔和其他形式的溝通可能會(huì)誤導(dǎo)人們——或許他們只是在談?wù)?Node.js 中的 ESM 發(fā)生了什么，而不是 ESM 本身的設(shè)計(jì)。去年，當(dāng) joyeecheung 在閱讀 V8 代碼以修復(fù)內(nèi)存泄漏問題時(shí)，他偶然發(fā)現(xiàn) ESM 本身并沒有被設(shè)計(jì)為無條件異步的。相反，它是有條件異步的——只有當(dāng)代碼中有頂級(jí) await 時(shí)，它才會(huì)是異步的。
所以，支持 require() 加載不包含頂級(jí) await 的 ESM 并沒有什么問題。雖然有些庫可能有正當(dāng)理由使用頂級(jí) await，但這可能并不常見。
事實(shí)上，當(dāng) joyeecheung 后來測(cè)試了 npm 注冊(cè)表上的大約 30 個(gè)僅通過 ESM 提供支持的包時(shí)，沒有一個(gè)包含頂級(jí) await——支持同步模塊的 require() 可能已經(jīng)解決了生態(tài)系統(tǒng)中的許多頭痛問題。
對(duì) ESM 的支持經(jīng)歷了長時(shí)間的討論、設(shè)計(jì)和實(shí)驗(yàn)。早在 2019 年，Node.js 社區(qū)就開始探索如何支持 ESM 和 CommonJS 之間的互操作性。在此期間，許多開發(fā)者提交了 Pull Requests，提出了不同的實(shí)現(xiàn)方案和改進(jìn)措施。
當(dāng)時(shí)，一個(gè)里程碑式的 PR 討論集中在如何在 Node.js 中支持 .mjs 擴(kuò)展名的文件以及如何實(shí)現(xiàn)同時(shí)支持 CommonJS 和 ESM 的雙模塊系統(tǒng)。
該請(qǐng)求嘗試通過在加載器中循環(huán)事件來處理頂級(jí) await，但其方法不安全，這就是它被關(guān)閉的原因。
在規(guī)范方面，基于語法的 ESM 同步評(píng)估的理論基礎(chǔ)在 2019 年已經(jīng)確立。隨著時(shí)間的推移，在 Node.js 中似乎形成了一個(gè)關(guān)于“ESM 是異步的，CJS 是同步的，因此 CJS 不能加載 ESM”的神話。然而，在標(biāo)準(zhǔn)組織中，ES 規(guī)范特別確保 ESM 是有條件異步的。W3C 規(guī)范使用它來確保 Service Workers 只允許同步模塊評(píng)估。如果在 2019 年之后，規(guī)范中的語法同步性被更廣泛地認(rèn)識(shí)到，可能會(huì)有更多的嘗試，文檔也不會(huì)無條件地討論 ESM 作為異步的。
去年底，joyeecheung 發(fā)現(xiàn)根據(jù)語法，ESM 可以是同步的，只有 Node.js 引入了異步到加載過程中。因此，joyeecheung 和 GeoffreyBooth 開始討論重啟同步 require(esm)。
在 2024 年 2 月底，當(dāng) joyeecheung 在為 CJS 和 ESM 加載器做類似緩存的工作并再次深入研究它們時(shí)，他注意到似乎有一個(gè)更簡單的實(shí)現(xiàn)方法——只需放棄“使 ESM 加載器成為 Node.js 中唯一加載器”的想法，并為 CJS 加載器實(shí)現(xiàn)一些專用程序以支持同步 require(esm)。使用的現(xiàn)有 ESM 加載器代碼越少，越容易實(shí)現(xiàn)。
于是，這個(gè) PR 誕生了。
https://github.com/nodejs/node/pull/51977。
與 2019 年的 PR 的主要區(qū)別在于，這次嘗試將 require(esm) 的范圍縮小，僅支持同步加載 ESM。事實(shí)證明，在技術(shù)指導(dǎo)委員會(huì)（TSC）中，這并不是一個(gè)有爭議的想法，并沒有引起太多爭議。
目前，該功能仍在通過 --experimental-require-module 標(biāo)志進(jìn)行實(shí)驗(yàn)，并且在退出實(shí)驗(yàn)階段之前需要完成一些工作。
目前，require(esm) 僅支持顯式標(biāo)記為 ESM 的 ESM 模塊——要么通過 .mjs 擴(kuò)展名，要么通過使用 .js 擴(kuò)展名的 “type”: “module” 包字段。這足以支持 npm 中的 ESM-only 包。當(dāng)一個(gè) .js 文件包含 ESM 語法并且其最近的 package.json 中沒有 “type”: “module” 字段時(shí)，它可以“回退”到 ESM 加載，但這是用戶應(yīng)該避免的事情——ESM 語法檢測(cè)會(huì)帶來開銷，一旦你的項(xiàng)目中有足夠的 ESM 模塊，你可能不希望 Node.js 浪費(fèi)時(shí)間猜測(cè)你的模塊類型。特別是，只需在 package.json 中使用顯式的 “type”: “module” 字段，就可以節(jié)省這些開銷。
老實(shí)說，這個(gè)問題困擾了我很長時(shí)間。許多 NPM 包開發(fā)者也深受其害。我希望 joyeecheung 的這次嘗試能夠盡快投入生產(chǎn)！
本文鏈接：http://m.www897cc.com/showinfo-26-94142-0.htmlCommonJS 和 ES Module 終于能夠互相兼容了
聲明：本網(wǎng)頁內(nèi)容旨在傳播知識(shí)，若有侵權(quán)等問題請(qǐng)及時(shí)與本網(wǎng)聯(lián)系，我們將在第一時(shí)間刪除處理。郵件：2376512515@qq.com
上一篇： 前端到底是“技術(shù)深度”重要還是“技術(shù)廣度”重要？
下一篇： 產(chǎn)能供不應(yīng)求，英偉達(dá)選擇讓利：消息稱臺(tái)積電將針對(duì)先進(jìn)制程和先進(jìn)封裝漲價(jià)
Copyright ? 2016-2023 天津谷騏科技有限公司 版權(quán)所有 sitemap.xml
違法及侵權(quán)請(qǐng)聯(lián)系：2376512515@qq.com 津ICP備18001702號(hào)
津公網(wǎng)安備 12010102000574號(hào)