Yarn如何共享嵌套依赖中的@react-native-picker/picker解决RNCPicker报错

这个tried to register two views with the same name RNCPicker报错，本质是原生模块的注册逻辑和源码路径强绑定：只要原生编译流程中识别到两份不同路径的@react-native-picker/picker源码，就会分别执行一次原生视图注册逻辑，最终触发同名冲突。
Yarn的依赖提升（hoisting）机制只负责在JS层合并同版本的嵌套依赖，不会主动强制删除物理存在于嵌套node_modules路径下的独立包目录。你之前执行的yarn why输出显示所有依赖来源对应的@react-native-picker/picker版本均为1.12.0，不存在版本错配，问题根源是依赖没有被完全打平到根node_modules路径下，嵌套残留的包目录被原生构建工具识别为独立模块完成编译，最终触发重复注册。
之前配置的resolutions没有生效，是因为没有触发锁文件和本地安装产物的全量刷新，Yarn会沿用旧的yarn.lock中记录的嵌套安装规则，不会主动应用新的版本约束。

• 在应用根目录的package.json中，将@react-native-picker/picker声明为直接生产依赖，版本与当前统一的1.12.0保持一致。这一步会强制Yarn优先在根node_modules路径部署该包，从依赖解析环节减少嵌套安装的概率。
• 清理所有旧的依赖残留：
  • 删除根目录下的node_modules文件夹
  • 删除锁文件yarn.lock
  • 执行yarn cache clean清空Yarn本地缓存
• 执行yarn install重新安装全量依赖，安装完成后再次运行yarn why @react-native-picker/picker，确认不存在嵌套在子包node_modules路径（比如node_modules/component-library/node_modules、node_modules/native-base/node_modules）下的独立@react-native-picker/picker目录。
• 清理原生构建的旧编译产物：
  • 安卓端：删除android/build、android/app/build目录
  • iOS端：进入ios目录执行pod deintegrate && pod install，重新安装原生依赖
• 以带缓存重置的参数启动Metro：执行yarn start --reset-cache，再重新编译运行应用。

由于component-library是自研的间接依赖包，可通过依赖声明调整从根源避免嵌套安装：

• 将@react-native-picker/picker从component-library自身的dependencies中移除，调整为peerDependencies，版本范围与主应用引入的版本保持匹配。peerDependencies机制会告知Yarn，该包使用的@react-native-picker/picker需要由上层应用统一提供，不会触发组件包内部的嵌套安装逻辑。
• 在component-library的devDependencies中补充对应版本的@react-native-picker/picker，仅用于组件包本地开发调试，发布到npm时不会强行锁定依赖版本。

• 手动删除嵌套路径下的@react-native-picker/picker目录仅为临时规避方案，每次重新执行yarn install时，Yarn会按照原有的依赖声明规则重新恢复嵌套目录，问题会反复出现。
• 如果使用Yarn 2+版本，需检查.yarnrc.yml中的nodeLinker配置，确保使用node-modules链接模式；若使用PnP模式，可能因模块解析路径的差异，让原生打包工具识别到两份独立的模块源码，触发重复注册报错。

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