Yarn依赖安装格式异常：移除yarn.lock为CommonJS，保留则为ES模块

核心原因拆解 #

这种同一依赖包出现两种模块格式的问题，本质是Yarn 1.x的依赖解析逻辑差异结合Node 18对模块规则的调整导致的，具体分几点：

• Yarn 1.x锁文件的路径固化特性：yarn.lock会精确记录安装时选中的依赖文件路径（比如node_modules/xxx/dist/esm/index.js），后续安装会直接复用这个路径，不会重新根据当前环境解析依赖的入口字段。而删除锁文件后，Yarn会重新读取依赖包的package.json（比如main、module、exports字段），结合当前Node环境的模块规则选择入口。
• Node 18对exports字段的优先级提升：Node 18对package.json的exports字段（用于区分CJS/ESM入口）处理更严格。如果依赖包同时提供了CJS和ESM两种分发格式，且通过exports字段明确区分，Yarn 1.x在无锁文件时会根据当前项目的模块模式（比如你的项目package.json是否设置type: "module"）选择对应入口；但旧的yarn.lock可能是在Node版本较低（对exports支持较弱）时生成的，固化了当时选中的ESM入口，导致环境切换后出现差异。
• Yarn 1.x版本兼容性问题：你使用的Yarn 1.22.19是较旧的版本，对Node 18的模块解析逻辑适配不足，在无锁文件和有锁文件时的入口选择逻辑出现不一致。

可行解决办法 #

1. 重新生成适配Node 18的yarn.lock
   删除旧的yarn.lock和node_modules，在Node 18环境下执行yarn install生成新的锁文件，提交这个新锁文件到仓库。这样所有环境安装时都会遵循Node 18下的解析规则，统一使用CJS格式的依赖。

2. 升级Yarn版本
   Yarn 1.x后续版本（比如1.22.20+）针对Node 18做了兼容性修复，或者直接升级到Yarn Berry（2.x/3.x），它的依赖解析逻辑更清晰，对ESM的支持更完善，能避免这类解析不一致的问题。

3. 用resolutions强制指定依赖入口
   在项目的package.json中添加resolutions字段，强制指定问题依赖使用CJS入口，比如：

   "resolutions": {
     "your-problem-package/dist/esm/index.js": "your-problem-package/dist/cjs/index.js"
   }
   

   这样无论有无锁文件，Yarn都会安装指定的CJS版本文件。

4. 检查项目与依赖的模块配置
   确认你的项目package.json是否设置了type: "module"——如果你的项目编译为ES6但作为其他项目的依赖（可能被CJS项目引用），建议移除type: "module"，让Node默认以CJS模式处理，这样Yarn解析依赖时会优先选择CJS入口。

内容的提问来源于stack exchange，提问作者Paulo Ricca