Question

我有这样的标准Lerna存储库：

my-repo
 - package.json
 - packages
   - api
     - package.json
   - web-app 
     - package.json

如果两个软件包都需要相同的依赖项（例如lodash），那么教程中的人建议将其安装到两个子模块中，然后使用lerna bootstrap --hoist标志引导项目。

由于--hoist标志lodash依赖关系将仅加载到根级别node_modules，但是两个子模块都将其作为依赖关系包含在其相应的package.json

但是Node的包解析算法会在文件树中搜索node_modules文件夹。

所以我的问题是为什么我不能仅将通用依赖项安装到根级项目？然后lodash将位于根的node_modules下。子模块（包）会找到它，因为Node会搜索node_module直到到达文件系统的根。

至少它会帮助我避免使用不常见的lerna bootstrap --hoist，以及lodash依赖项仅在顶级package.json上出现一次（而不是两次：在{{1 }}两个子模块）

Answer 1

所以我的问题是为什么我不能仅将通用依赖项安装到root用户级项目？

您可以并且很正确，节点的解析算法将发现共享依赖关系很好。这样做的缺点是您失去了灵活性，因此您将需要部署或使用整个mono-repo，这可能对您很合适。一种更传统的方法是将生产依赖项保留在子包中，以便您可以发布包并单独使用它们，而不必依赖monorepo的根，但这再次对您而言并不重要。

Answer 2

如果你的包是 npm 包，你打算通过发布到一些 npm 注册表来重用，那么你应该给它们适当的 package.json 依赖。

一个包应该总是列出它需要什么来运行。例如。如果你的“api”包在运行时需要 lodash，那么它的依赖项中必须有 lodash。否则应用程序可以在没有 lodash 的情况下安装它；那么它将无法运行。

在你的 lerna 仓库中，你的“root”package.json 没有连接到任何 npm 包，也没有发布，所以它不会影响你的“真实”npm 包：“api”和“web-app” .

最后，如果你不打算将你的包发布为 npm 包，那么做你想做的任何事情。在这种情况下，Lerna 可能有点矫枉过正。甚至 package.json 也太过分了，因为它只是用于它的 scripts。