注：本文最初发表于pika.dev。
时间是1941年。你的名字叫理查德·哈贝尔。你在哥伦比亚广播公司（CBS）旗下的一家位于纽约的实验性电视演播室工作。你即将播报世界上最早的几条重要电视新闻，有15分钟的播出时间。你会怎么做？
在一个只有广播的世界里，人们只能依赖自己熟悉的东西，也就是阅读新闻。“大多数（电视）新闻播报都是哈贝尔照本宣科，偶尔穿插一些地图或静态照片。” [1]电视新闻播出真正的视频片段还需要一段时间。
作为一名2019年的JavaScript开发者，我深有同感。我们有了全新的JavaScript模块系统（ESM），它可以在Web上原生运行。然而，我们仍然对所有构建的东西都使用打包工具。为什么呢？
过去几年，JavaScript 打包已经从仅用于生产环境的优化转变为大多数 Web 应用程序必不可少的构建步骤。无论你喜欢还是讨厌这种变化，都很难否认打包工具给 Web 开发带来了大量新的复杂性——而 Web 开发领域一直以来都以其“查看源代码”和“易于上手”的理念而自豪。
@pika/web 旨在让 Web 开发摆脱对打包工具的依赖。在 2019 年，你应该因为想要使用打包工具而使用它，而不是因为不得不使用它。
JavaScript 打包是对一个古老概念的现代诠释。想当年（哈哈，大概六年前），在生产环境中，通常会将 JavaScript 文件压缩并合并在一起。这样做可以加快网站速度，并绕过HTTP/1.1 协议中 2 个以上并行请求的限制。
这种锦上添花的优化是如何变成开发人员的绝对必需品的呢？嗯，最不可思议的是：大多数 Web 开发人员从未明确要求过打包。相反，打包是另一个东西的副作用，而我们非常非常需要它：npm。
npm——当时是“Node.js 包管理器”的缩写——正朝着史上最大的代码仓库迈进。前端开发者们也想参与其中。唯一的问题是，它基于 Node.js 的模块系统（Common.js 或 CJS）如果不进行打包，就无法在 Web 上运行。于是，Browserify、Webpack以及现代的 Web 打包工具应运而生。
如今，几乎不可能在不使用Webpack之类的打包工具的情况下构建 Web 应用。希望你能使用Create React App (CRA)之类的工具快速入门，但即使是这样，node_modules/仅仅为了运行“Hello World!”程序，也会安装一个包含 1300 多个不同依赖项的复杂目录，该目录大小为 200.9MB。
就像 Richard Hubbell 一样，我们都太沉浸于打包工具的世界里，以至于很容易忽略事情本可以有不同的发展方向。我们现在拥有这些优秀的、现代化的 ESM 依赖项（npm 上就有近 5 万个！）。是什么阻止我们直接在 Web 上运行它们呢？
嗯，有几点需要说明。😕 自己编写 Web 原生 ESM 代码并不难，而且确实有一些没有依赖项的 npm 包可以直接在 Web 上运行。但遗憾的是，大多数包仍然无法运行。这可能是由于包本身的旧版依赖项，也可能是由于 npm 包通过名称导入依赖项的特殊方式造成的。
这就是创建 @pika/web 的原因。
FredKSchott /雪堆更新（2022 年 4 月 20 日）： Snowpack 已停止积极维护，不建议在新项目中使用。
Snowpack 是一款速度极快的前端构建工具，旨在充分利用 JavaScript 的原生模块系统（ESM）。它可作为开发工作流程中 Webpack 或 Parcel 等更繁琐、更复杂的打包工具的替代方案。
💁 更多信息请访问 Snowpack 官方网站 ➞
贡献者指南： CONTRIBUTING.md
许可证： MIT
@pika/web以一种让现代 npm 依赖项能够在浏览器中原生运行的方式进行安装，即使它们本身也有依赖项。仅此而已。它不是构建工具，也不是（传统意义上的）打包工具。@pika/web 是一个依赖项安装时工具，可以显著减少对其他工具的需求，甚至完全跳过 Webpack或Parcel。
npm install && npx @pika/web
✔ @pika/web installed web-native dependencies. [0.41s]
@pika/web 会检查你的package.json清单文件中是否"dependencies"存在导出有效 ESM“模块”入口点的文件，并将其安装到本地web_modules/目录。@pika/web 适用于任何 ESM 包，即使是那些内部依赖 ESM 和 Common.js 的包也适用。
已安装的软件包之所以能在浏览器中运行，是因为 @pika/web 将每个软件包打包成一个单独的、可用于 Web 的 ESM.js文件。例如：整个“preact”软件包会被安装到web_modules/preact.js。这既解决了软件包内部可能存在的任何错误，又保留了原始的软件包接口。
“啊哈！”你可能会说。“那只是把捆绑包装藏在了另一个地方！”
没错！ @pika/web 内部利用打包功能输出 web 原生 npm 依赖项，这正是我们很多人最初开始使用打包工具的主要原因！
借助 @pika/web，打包器的所有复杂性都被集成到一个安装时即可使用的工具中。如果您不想，完全无需修改任何打包器配置。当然，您也可以继续使用其他任何您喜欢的工具：增强您的开发体验（Babel、TypeScript）或优化您的生产环境部署方式（Webpack、Rollup）。
这就是 @pika/web 的全部意义所在：因为你想这样做而打包，而不是因为你需要这样做。
以这种方式（将每个依赖项作为单个 JS 文件安装）相比大多数打包工具配置，可以带来一项显著的性能提升：依赖项缓存。当您将所有依赖项打包到一个大vendor.js文件中时，更新其中一个依赖项可能会导致用户重新下载整个包。而使用 @pika/web，更新单个包不会破坏用户的其他缓存。
@pika/web 可以帮你避免打包工具引入的这类性能陷阱。例如，不同打包文件中的重复代码、由于未使用/无关代码导致的首页加载缓慢、Webpack 生态系统升级带来的各种问题和 bug …… 已经有大量的文章和工具致力于解决这些问题。
需要说明的是，即使应用程序源代码不打包，也并非全是好事。大型 JavaScript 文件在网络传输过程中比小型、更细粒度的文件压缩效果更好。虽然多个较小的文件通过HTTP/2也能正常加载，但浏览器在发出后续导入请求之前，需要花费一些时间来解析这些文件。
归根结底，这需要在性能、缓存效率以及你能接受的复杂度之间做出权衡。再次强调，这正是 @pika/web 的核心理念：添加打包工具是因为它符合你的需求，而不是因为你别无选择。
@pika/web 彻底改变了我们进行 Web 开发的方式。以下是我们构建pika.dev 的过程，以及我们建议您在 2019 年构建下一个 Web 应用程序的方式：