這里指的 ES Modules (esm)是指源代碼中使用 'import','export' 方式導入或導出模塊.

這種方式成為標準已經好幾年了, 各大瀏覽器廠商全部支持這種寫法:

<script type="module"> import mod from 'https://dev.jspm.io/npm:some-module'; </script> 復制代碼

問題:? 模塊開發者發布什么樣的的文件才能最好的支持這種方式.

我們知道以往的通用做法是使用?require,?module.exports, 如果你的模塊是這種方式, 那 jspm.io 可以解決多數兼容性問題(畢竟具體寫法有很多, jspm 不一定能全部理解和正確處理).

顯然 jspm 為這種加載方式付出了額外的工作, 服務器端進行轉換, 二次包裝, 甚至多次請求.

那么如何使這種成本最低, 也就是所謂的正確姿勢?

兩種方法:

采用同時兼容 CJS 和 esm 的格式, 優點: 一個文件解決兼容性

分離文件, '.js' 文件使用傳統 CJS 風格, '.mjs' 文件使用 esm 格式, 優點: 干凈

第一種方式的例子:?https://unpkg.com/@babel/parser@7.0.0-beta.48/lib/index.js

這是社區使用的兼容方式:?Object.defineProperty(exports, '__esModule', { value: true });

第二種會有兩個文件: '.js' 和 '.mjs' 的, 其中 '.js' 的不包含 'import','export', '.mjs' 至少要包含 'export'

打包工具通常都支持多種方式(打包工具就是干這個的), 比如 rollupjs

糟糕的方法:

擴展名是 '.js', 里面卻使用了 'import','export'. 正如前文所述, 會增加加載成本,?這方法過時了.

擴展名是 '.mjs' 里面卻使用 'require' 或者沒有使用 'export'. 這完全誤用了 '.mjs', 這樣用就失去了 '.mjs' 被創造出來意義.

現實中, 很多項目在打包的時候不會考慮到加載成本, 這是一種慣性, 隨著時間的推移可能會改變, 也可能會更糟糕. 因為如果多數開發者都不在乎 '.mjs' 這個擴展名的話, 問題只會越來越混亂.

總結

以上是生活随笔為你收集整理的模块开发者使用 ES Modules 的正确姿势的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。