Pinia 4.0 全面 ESM-only：前端模块化，终于只剩一条路

下班之后没人亲亲，敲段代码哄自己开心。写个demo修完bug，誓让女神喊你哥哥。

当 Vue 的官方状态库也摘下了 CommonJS 的帽子，说明一件事：那个”既要又要”的兼容时代，正在落幕。

一个不起眼但重要的变化

Pinia 4.0 发布，最关键的改动不是某个 API，而是发布形态：只提供 ESM（ECMAScript Modules）构建，不再提供 CommonJS（CJS）/ UMD 版本。

翻译成人话：如果你还在项目里用 require('pinia')，升到 4.0 会直接给你报错。

不是孤例：ESM-only 正在成为”默认选项”

过去两年，越来越多的重量级库宣布”只发 ESM”：

• Vite 早已彻底 ESM-only，并顺势放弃了对旧版 Node 的兼容；
• 大量底层工具库（文件监听、路径处理、CLI 框架）陆续摘掉 CJS 构建；
• 连 Node.js 自身，也在不断弱化对 CJS 的特殊照顾，把 ESM 推上主桌。

一个清晰的趋势浮出水面：ESM 正在成为 JavaScript 事实上的唯一模块标准。

为什么是现在？

这件事背后，是前端十年模块化的”合流”：

1. 浏览器原生支持 ESM（<script type="module">）早已普及，到今天不是新鲜事；
2. 构建工具全面倒向 ESM：Vite 的核心思路就是”利用浏览器原生 ESM 做开发服务器”，从根上跳过了打包；
3. Tree-shaking 成为刚需：ESM 的静态结构让打包器能精准剔除没用到的代码，CJS 的动态特性做不到这一点；
4. Node 生态成熟：主流 Node 版本对 ESM 已是原生友好，兼容层不再是”保命绳”。

当浏览器、构建工具、运行时（Node）三端都对齐到 ESM，库再维护一套 CJS 构建，就成了”为了极少数旧场景，拖累所有人的负担”。

对开发者，到底意味着什么？

影响一：老项目别急着追新。 如果老的项目用着 require 直接引包、或跑着老版本 Node 的项目，升级 Pinia 4.0 会直接挂。

影响二：新项目反而更省心。 Vite + Vue 3 + ESM-only 的库，是一条已被验证顺滑的路径。少了 CJS 兼容层，包体积更小、构建更干净。

影响三：Node 版本门槛抬高。 ESM-only 往往伴随”最低 Node 版本”的抬升。团队统一 Node 版本管理（nvm / volta / fnm）成了绕不开的配套动作。

影响四：工具链的”翻译层”会消失。 过去 cjs→esm 的胶水代码、双构建发布流程，会逐步退出历史舞台。库的维护者能把精力从”兼容八国语言”转移到”把单一形态做好”。

更深一层：前端在”收敛”

把这几年的变化连起来看，会发现一个清晰的方向——前端技术正在从”百花齐放、各自为政”走向”标准收敛”：

• 模块标准：CJS + AMD + UMD + ESM 混战 → ESM 一家独大
• 构建思路：打包一切 → 拥抱原生 ESM（Vite / Rollup）
• 运行时：浏览器 + Node 双轨 → 边缘函数 / SSR 边界模糊
• 类型系统：JSDoc → TypeScript 成为事实标准

收敛不是倒退，而是生态成熟的表现：当基础层达成一致，开发者才能把精力从”解决兼容”转移到”创造价值”。

结语

Pinia 4.0 的 ESM-only，单看只是发布说明里一行小字。

但把它放进前端这十年的坐标系里，它是一条清晰的分界线：那边的世界，我们还在小心翼翼地兼容每一种写法；这边的世界，标准已经统一，剩下的只是往前走。

技术演进最迷人的地方，从来不是某个工具多厉害，而是当一群人默契地选择了同一个方向，整个行业的摩擦力，就这样被悄悄抹平了。

对开发者，这既是提醒也是红利：提醒你别再拖延模块化的迁移，红利是——未来的工具，会更轻、更纯粹、更值得期待。