引言
已经有越来越多前端开发者放弃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个包：
react
scheduler
object-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服务一定能大放异彩。
