大家好，我卡颂。

曾经有越来越多前端开发者放弃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服务肯定能大放异彩。