为何依赖其他依赖项是不良实践？共享核心依赖的风险问询

咱们先聊第一个问题：为什么直接用其他依赖的子依赖是公认的不良实践？主要有这几个核心问题：

• 版本完全不可控：子依赖的版本是由上层依赖的package.json决定的，一旦上层依赖发布新版本（哪怕只是小版本更新），它可能会升级、降级甚至移除这个子依赖。你的代码毫无预兆就可能因为子依赖的API变化、bug引入而崩溃，完全没有主动权。
• 兼容性冲突风险：如果你的项目里有多个上层依赖都依赖同一个子依赖的不同版本，包管理器（npm/yarn/pnpm）的依赖树扁平化逻辑可能会导致版本冲突，甚至同时安装多个版本。比如两个版本的node-sass可能会导致编译时出现奇怪的路径错误，或者运行时的样式渲染异常。
• 依赖树稳定性差：你的项目package.json里没有声明这个子依赖，相当于它是“隐式依赖”。哪天上层依赖的维护者决定移除这个子依赖，你执行npm install后，项目直接就会报模块找不到的错误，排查起来非常麻烦。
• 可维护性极低：其他开发者接手你的项目时，看package.json根本不知道你实际用到了slick-slider这类包。想升级某个子依赖版本、排查相关bug时，都得先去翻上层依赖的依赖树，沟通和排查成本直线上升。

再来说你的特定场景：三个项目共享一个前端Core，把slick-slider、node-sass这类依赖只装在Core里，项目通过Core来访问。除了看不到依赖列表外，还有这些容易被忽略的弊端：

• 项目耦合度过高：如果其中一个项目需要单独调整某个子依赖的版本（比如要用到slick-slider的新特性，或者需要降级修复某个bug），你只能去修改Core的依赖版本，这会直接影响另外两个项目——它们被迫同步升级/降级，很可能出现兼容性问题，完全没法单独定制。
• 调试复杂度飙升：比如某个项目里slick-slider出现了渲染bug，你得先确认Core的版本、Core里slick-slider的版本，还要检查项目安装的Core是不是最新版，甚至要排查Core对slick-slider的封装有没有修改过API，比直接在项目里装依赖的调试流程复杂得多。
• 不必要的包体积冗余：如果某个项目其实只用到了Core里一部分依赖，但因为依赖Core，你不得不把Core的所有依赖都装进去。哪怕tree-shaking能优化一部分，要是Core对这些依赖做了封装导出，还是可能把没用的代码打包进去，增加项目的构建体积和加载时间。
• 发布流程繁琐：每次要更新slick-slider这类依赖，都得先更新Core的package.json、发布Core新版本，再让三个项目都更新Core的依赖版本才能生效。如果某个项目暂时不想升级（比如担心新版本有bug），就没法单独使用新的子依赖版本。
• 依赖控制权受限：如果Core是由其他团队维护的，你完全没法直接控制里面的依赖版本。万一Core维护者移除了你需要的依赖，或者升级到不兼容的大版本，你的项目就得被迫做大量适配工作，非常被动。

小建议 #

如果你的核心需求是保持三个项目的依赖版本同步，其实可以试试更合理的方案：

1. 用Monorepo工具（比如npm Workspaces、pnpm Workspaces、Lerna）管理三个项目和Core，在根目录的package.json里统一声明共享依赖的版本，每个项目可以按需引入，既保证版本同步，又能让每个项目的package.json清晰显示用到的依赖。
2. 让Core通过**peerDependencies**声明它需要的slick-slider、node-sass等依赖，要求三个项目必须安装符合版本范围的对应依赖。这样每个项目的package.json里都会明确列出这些依赖，同时Core可以确保项目使用的版本是兼容的，也能灵活调整每个项目的版本（只要符合范围）。

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