Jotai 3.0 Ships as a Modernized, ESM-Only Package That Drops Legacy Builds and Deprecated APIs

Jotai 3.0 以现代化、仅 ESM 的包发布，放弃旧版构建和已弃用的 API

作者：Daniel Curtis · InfoQ 原文

摘要：Jotai 3.0 版本以仅支持 ES 模块的形式发布，移除了 CommonJS、UMD、SystemJS 等旧构建，以及老旧的 Node、React 和 TypeScript 支持。尽管一些公开 API（如 atomFamily、loadable 和 setSelf）被移除，但它们已在 v2 后期被标记为弃用，因此团队称其为“无破坏性变更”。迁移主要涉及导入路径的调整，例如 atomFamily 现在位于专用包 jotai-family 中。这次更新旨在精简核心，并巩固 Jotai 作为原子状态管理库的地位。

Jotai, the atomic state management library for React maintained under the Poimandres collective, has published its v3.0.0 stable release, which the team introduced as "a modernized ESM-only package with no breaking changes and no new APIs."

Jotai，这个由 Poimandres 社区维护的 React 原子状态管理库，现已发布 v3.0.0 稳定版，团队将其描述为“一个现代化的仅支持 ESM 的包，没有破坏性变更，也没有新增 API”。

The releases page echoes that framing, calling it "a mostly backward-compatible update, dropping some legacy support and deprecated APIs."

发布页面也呼应了这一说法，称其为“一个基本向后兼容的更新，放弃了一些旧版支持和已弃用的 API”。

v3 drops the CommonJS build entirely and ships as ES modules only, alongside removed UMD and SystemJS bundles, older Node, React and TypeScript support, and the jotai/babel plugin.

v3 版本完全移除了 CommonJS 构建，仅以 ES 模块形式发布，同时删除了 UMD 和 SystemJS 包、对老旧 Node、React 和 TypeScript 的支持，以及 jotai/babel 插件。

The package moves to a module-first structure, targets ES2020, reads NODE_ENV directly instead of using build-time replacement, and swaps Rollup for other build tooling.

该包转向了以模块优先的结构，以 ES2020 为目标，直接读取 NODE_ENV 而不再使用构建时替换，并用其他构建工具替换了 Rollup。

Maintainer Daishi Kato has long documented the dual package hazard of shipping both CJS and ESM, so the ESM-only stance reads as the conclusion of that work, and the payoff is a leaner core with less to maintain.

维护者 Daishi Kato 长期以来一直记录同时发布 CJS 和 ESM 的双包风险，因此仅支持 ESM 的立场可以被视为这项工作的结论，其回报是一个更精简、维护工作更少的核心。

The "no breaking changes" claim comes with an asterisk as several public APIs are gone, including atomFamily, loadable and the setSelf argument to atom read functions, but each had already been deprecated across the late v2 line, so teams that heeded those warnings should upgrade cleanly.

“无破坏性变更”的说法带有一个星号，因为几个公共 API 已经消失，包括 atomFamily、loadable 以及 atom 读取函数中的 setSelf 参数，但每个都在 v2 后期已被弃用，因此留意这些警告的团队应该能顺利升级。

The internal building blocks API has also been redesigned.

内部构建模块 API 也经过了重新设计。

Projects still importing through CommonJS or relying on the removed builds are the ones most likely to feel the shift.

仍然通过 CommonJS 导入或依赖被移除构建的项目最可能感受到这一变化。

Migration is meant to be mechanical for most teams.

对大多数团队来说，迁移是机械化的。

atomFamily now lives in the dedicated jotai-family package with an identical API plus a new atomTree helper, so the change is a single import swap:

atomFamily 现在位于专用的 jotai-family 包中，具有相同的 API 和一个新的 atomTree 辅助工具，因此变更只是单一的导入替换：

// Before (v2)

// 之前 (v2)

import { atomFamily } from 'jotai/utils'

// After (v3)

// 之后 (v3)

import { atomFamily } from 'jotai-family'

loadable users are pointed toward jotai-eager, and the full path is documented in the v3 migration guide.

loadable 的用户被指引使用 jotai-eager，完整路径在 v3 迁移指南中有文档说明。

In the Ideas for v3 thread, one user pushed back on removing setSelf, describing an optimistic atomWithStorageWhileRevalidate pattern that hydrates from localStorage while fetching fresh server data and has no clean replacement without it.

在“v3 想法”的讨论帖中，一位用户反对移除 setSelf，描述了一种乐观的 atomWithStorageWhileRevalidate 模式，该模式在获取新服务器数据的同时从 localStorage 进行水合，没有它就没有干净的替代方案。

The same thread carries a detailed request for a first-class default store lifecycle so tests can reset state without reaching into internal APIs, a real pain point for large apps that lean on getDefaultStore().

同一个讨论帖中还包含一个详细请求，希望拥有头等地位的默认 store 生命周期，以便测试无需触及内部 API 就能重置状态，这对于依赖 getDefaultStore() 的大型应用来说是一个真正的痛点。

In a separate discussion, Kato confirmed that new features and deeper breaking changes were deliberately out of scope for 3.0, steering concurrent-safe atoms and external-store syncing toward a later v3.x or a future v4.

在另一场讨论中，Kato 确认新功能和更深层的破坏性变更被有意排除在 3.0 的范围之外，将并发安全的 atoms 和外部 store 同步引导至后续的 v3.x 或未来的 v4。

Facebook's Recoil, the project that popularised atoms, is now widely treated as deprecated, leaving Jotai as the de facto successor for the atomic model, while its Poimandres sibling Zustand holds the store-centric camp for teams that prefer a single external store.

Facebook 的 Recoil，那个普及了原子概念的项目，现在被广泛视为已弃用，这使得 Jotai 成为原子模型的事实上的继承者，而其 Poimandres 兄弟 Zustand 则占据了以 store 为中心的阵营，服务于偏好单一外部 store 的团队。

By making 3.0 a cleanup rather than a reinvention, the team is betting that a smaller, modern, ESM-native core is the more valuable upgrade for the ecosystem it now anchors.

通过将 3.0 作为一次清理而非重新发明，该团队押注于一个更小、更现代、原生支持 ESM 的核心，对于它所锚定的生态系统来说，会是更有价值的升级。

Jotai takes an atomic approach to React state, building state from small units called atoms and combining them into a dependency graph so renders update only where values actually change.

Jotai 对 React 状态采用原子化方法，从称为 atoms 的小单元构建状态，并将它们组合成一个依赖图，使得渲染只在实际值发生变化的地方更新。

It is unopinionated and can run outside React through a standalone store, and 3.0 is now the stable line, available on npm for teams ready to move off the v2 releases.

它没有意见倾向，并且可以通过独立 store 在 React 之外运行，3.0 现在是稳定版本，在 npm 上可供准备从 v2 版本迁移的团队使用。

阅读理解

1. Which of the following is explicitly removed from Jotai v3.0, according to the article?

2. What does the article indicate about the API named 'setSelf' in Jotai v3.0?

3. According to the article, what is the main argument for making Jotai 3.0 an ESM-only package?

温故复习 →每日一句 →