Nuqs 项目中 ESM 与 CJS 模块兼容性问题解析

问题背景

在 Nuqs 2.0.0 版本发布后，部分开发者在使用 Next.js 应用路由时遇到了一个特殊的 ESLint 错误。当开发者尝试从 'nuqs/adapters/next/app' 导入 NuqsAdapter 时，ESLint 会抛出错误："Package subpath './adapters/next/app' is not defined by 'exports'"。

问题本质

这个问题的根源在于 Node.js 模块系统的兼容性问题。Nuqs 2.0 版本采用了纯 ESM (ECMAScript Modules) 格式，而项目中的 ESLint 及其插件（特别是 eslint-import-resolver-alias）仍然运行在 CommonJS (CJS) 环境下。

当 ESLint 尝试解析模块路径时，它会检查 package.json 中的 exports 字段。在纯 ESM 包中，通常只定义了 import 和 types 字段，而没有为 require 场景提供兼容性支持。这导致 ESLint 的模块解析器无法正确识别模块路径。

技术细节分析

1. 模块解析机制：Node.js 的模块解析器会根据 package.json 中的 exports 字段来验证导入路径的有效性。在 ESM 包中，如果没有为 CJS 环境定义 require 字段，CJS 工具链就无法正确解析模块路径。

2. ESLint 的特殊性：虽然 ESLint 8+ 版本本身支持 ESM，但许多 ESLint 插件（特别是那些依赖 resolver 的插件）仍然以 CJS 形式运行。eslint-import-resolver-alias 就是一个典型的 CJS 包，它已经有6年没有更新了。

3. 解决方案对比：

   • 临时解决方案：在本地修改 package.json，为 require 字段添加一个指向 ESM 文件的路径
   • 更优方案：为 require 字段提供一个空的 CJS 文件作为占位符

最终解决方案

Nuqs 团队最终采用了提供空 CJS 文件的方案，这既解决了 ESLint 的模块解析问题，又避免了将 ESM 代码错误地用于 CJS 环境可能带来的潜在问题。这个方案在 2.0.3 版本中得到了实现。

开发者启示

1. 当项目从 CJS 迁移到 ESM 时，需要考虑工具链的兼容性问题，特别是那些长期未更新的工具。

2. 在 package.json 的 exports 字段中，合理定义 import 和 require 的映射关系是确保跨模块系统兼容性的关键。

3. 对于库开发者来说，提供清晰的迁移指南和已知问题说明可以帮助用户更快地解决问题。

这个问题也反映了 JavaScript 生态系统中模块系统过渡期的典型挑战，理解这些底层机制有助于开发者更好地应对类似问题。