Next.js项目Yarn工作区子包应选用CommonJS还是ES Module？

当前ES模块子包可正常运行的原因 #

• Next.js 12及以上版本已原生支持ES模块，同时默认会将同仓库Yarn工作区的本地依赖纳入内置转译范围，不需要额外配置next-transpile-modules。你之前遇到的unexpected token: export报错，本质是第三方发布到npm的ES模块包默认不会被Next.js转译，Node.js运行时在CJS上下文中无法识别ESM的export语法导致的，和本次本地工作区依赖的场景完全不同。
• 你使用workspace:*声明的@api依赖会被Yarn软链接到本地的/api目录，Next.js的构建工具会将其识别为项目内部代码而非第三方node_modules依赖，会自动执行转译处理，不管你输出的是ES模块还是CommonJS模块，都会被转换为适配Next.js运行环境的代码格式，因此不会出现语法报错。
• 你的/api包配置中未在package.json中声明"type": "module"，此时输出的.js后缀文件会被Node.js默认识别为CommonJS格式，即使TS编译产出的是ES6模块语法，Next.js的转译流程也会自动处理语法兼容，不会出现运行冲突。

Yarn工作区子包的模块规范选择建议 #

• 如果子包仅为同仓库内部项目使用：优先选择ES Module，可获得更好的tree shaking效果，减少构建产物体积，同时适配Next.js、Vite等主流现代前端工具的默认配置，不需要额外做兼容处理。
• 如果子包需要对外发布到npm供第三方使用：建议同时输出CommonJS和ES Module两种格式，在package.json中通过main（CJS入口）、module（ESM入口）、exports字段声明多入口，兼容不同使用场景。
• 如果子包仅在Node.js服务端场景使用：可根据Node.js版本选择，Node.js 14.13.0及以上已完全支持ES Module，若不需要兼容低版本Node.js可直接选用ES Module，否则选择CommonJS。

内容的提问来源于stack exchange，提问作者Junhee Park