大家好，我卡頌。
已經有越來越多前端開發者放棄webpack，改用vite作為專案打包工具。
其中最主要的原因是 —— vite在開發環境基於ESM規範實現的Nobundle模式，節省了程式碼打包的時間（當然，也有ESBuild的功勞）。
而在生產環境，當前仍有打包的需求。
隨著瀏覽器的迭代，ESM規範相容性越來越好，終有一天會進入生產環境大面積可用的狀態。
屆時生產環境打包將不再是剛需。
另一方面，從HTTP協議的角度看，在HTTP/1.1時代，多個模組被打包成一個檔案能減少瀏覽器併發請求數，達到優化目的。
但在HTTP/2多路複用普及後，這麼做的意義就不大了。
可以說，當這些基建成熟後，生產環境使用ESM模組是水到渠成的事情。
很多團隊預感到這點，很早就開始佈局相關產品。今天要介紹的Skypack就是這樣一款產品。
歡迎加入人類高質量前端框架群，帶飛
不一樣的CDN
Skypack首次釋出於19年6月（曾用名Pika CDN），是一款基於ESM規範的CDN服務。
在瀏覽器中，常見的CDN服務通常以script標籤的形式引入UMD規範的程式碼，以ReactDOM舉例：
<script crossorigin src="https://unpkg.com/react-dom@18.2.0/umd/react-dom.development.js"></script>程式碼執行後會在全域性暴露物件window.ReactDOM。
一些情況下，一個包還會依賴其他包，比如ReactDOM還會依賴如下3個包：
Reactschedulerobject-assign
為了應對這種情況，在生產環境開發者通常會將第三方依賴統一打包。
而Skypack以ESM規範引入程式碼：
// 在業務程式碼中引入如下語句
import ReactDOM from 'https://cdn.skypack.dev/react-dom';瀏覽器會依次發起對包及其依賴的請求：
配合上瀏覽器的Module Preload特性，可以讓這些資源統一預載入。
這就解決了第三方依賴需要打包的問題。
按需polyfill
如果你訪問上述CDN連結（https://cdn.skypack.dev/react...），會發現返回的結果並不是ReactDOM的程式碼，而是下面兩句export語句：
export * from '/-/react-dom@v17.0.1-oZ1BXZ5opQ1DbTh7nu9r/dist=es2019,mode=imports/optimized/react-dom.js';
export {default} from '/-/react-dom@v17.0.1-oZ1BXZ5opQ1DbTh7nu9r/dist=es2019,mode=imports/optimized/react-dom.js';語句的背後才是ESM規範的ReactDOM程式碼。
之所以這麼做是因為：Skypack會根據目標瀏覽器的UA為瀏覽器提供適合的包。
在高版本Chrome中的程式碼不需要polyfill，而在低版本IE中的程式碼需要polyfill，所以不同目標瀏覽器拿到的是不同的ReactDOM程式碼。
上述export語句中雜湊（oZ1BXZ5opQ1DbTh7nu9r）的不同就對應同一個版本的ReactDOM經過不同程度polyfill後的不同結果。
此外，在url後加min能得到壓縮後的程式碼：
import ReactDOM from 'https://cdn.skypack.dev/react-dom?min';接下來讓我們看看Skypack是如何處理請求的。
處理請求的流程
並不是所有包都有ESM規範的產物（React就沒有），當以如下url格式訪問任意包時：
// xxx替換為任意包名
import React from 'https://cdn.skypack.dev/xxx';如果之前從未有人訪問過這個包，則會構建包及其依賴的ESM產物並返回。
比如ReactDOM本身只提供UMD規範的產物，第一個訪問他的Skypack CDN連結的使用者會經歷如下步驟：
- 收集
ReactDOM及其依賴 - 將
ReactDOM及其依賴變為ESM規範 - 構建不同
polyfill程度的ESM產物 - 根據目標瀏覽器
UA返回對應的ReactDOM
在ReactDOM的產物程式碼中可以看到，他依賴的三個包已經轉為ESM規範：
總結
除了Skypack外，esm.sh也是類似功能的ESM CDN服務。
等到前端基建成熟的那天，相信這些ESM CDN服務一定能大放異彩。