Geo*_*ali 9 javascript workspace dependencies npm yarnpkg
所以，我知道这个图块并没有说明太多，但我有以下问题。我正在开发一个使用纱线工作区的项目。到目前为止我有 2 个工作区。让我困惑的一件事是：公共依赖项是否应该保留在根项目（描述工作区的项目）中？我目前在根项目中有一些常见的（我的意思是它们在两个工作区中都使用）依赖项，在工作区 package.json 中有一些（非常见）依赖项。
我还有一个问题需要帮助，但我觉得它与上一个问题有关。每当我进入工作区文件夹时，我yarn add <dep name>的一些依赖项就会消失。我必须回到根目录，删除yarn.lock并运行yarn。现在所有依赖项都已安装并位于正确的位置。
我觉得我失去了一些东西。我进行了很多研究，但无法找到好的“最佳实践”示例/文章。我希望你们中的一些人能够实现“正确的公式”并能够帮助我。
已经过去很长时间了，这个问题仍然没有答案。然而，我并没有停止寻找答案，并可以分享我的观点。
\n如果您想要 TLDR：影响工作区的所有模块都应该位于工作区的根目录中，并且所有项目依赖项都应该位于每个项目的文件夹中（所以是的，我们可能会在所有项目文件夹中拥有一个库）。另外，请尽量在所有工作区包中使用相同版本的节点模块。（如果您在一个包中使用 React 18.1.5，那么所有其他工作区应该是相同的）
\n现在来说说长话……
\n首先，事情已经发生了变化，工具也在不断发展，许多新出现的工具可以帮助我们完成任务。考虑到这一点，我将分享我所做的事情。
\n当我第一次开始使用工作区时，它们还不是很精致，lerna即将被弃用。然后我必须做的是非常小心版本控制并确保所有项目都使用相同版本的库。直到今天仍然建议这样做，但我们可以解决它。
\n为什么有必要这样做？因为yarn用于搜索库的方式。例如，假设我们有以下文件夹结构。
\nnode_modules (lodash v2)\npackages\n|_webapp-a (lodash v1)\n |_node_modules (lodash v1)\n|_webapp-b (lodash v2)\nwebapp-a我认为这里使用它的 v1 lodash 节点模块是有意义的，但我完全错了。由于某种原因，旧版本的纱线工作区和 lerna 总是使用找到的最高版本。最近这种情况不再发生了。
这里或多或少是相同的情况，唯一的区别是您可以更自由地为每个项目放置全局 npm 模块，但不建议这样做，我也不建议这样做。让我解释一下为什么这对我来说是一个坏主意。考虑具有以下文件夹结构：
\nnode_modules\npackages\n|_webapp-a (uses jQuery) // jokes on me nobody uses that in 2023\n|_webapp-b (uses jQuery)\n|_service-a (doesn't use jQuery)\n|_service-b (doesn't use jQuery)\npackage.json (adds jQuery globally)\n是的，这可行，即使服务 a 和 b 在某个时候决定使用更高版本的 jQuery，\xe2\x80\x99 也不会成为问题。当您想要打包这些项目进行生产时，最大的障碍就出现了。在我的机器上，我运行yarn install并且不关心文件大小，因为我希望能够运行所有项目，但是如果我只为 docker build service-a，当我使用全局时package.json会安装一些不必要的库，这会花费我的构建时间和容器磁盘空间。
首先我必须说 lerna 并不能替代纱线工作区。如果可能的话，Lerna 甚至在幕后使用纱线工作区。除此之外，它还提供了一些非常有用的工具，帮助我们运行项目、跟踪依赖关系、为我们提供更好的日志等。它现在由 Nrwl 维护，Nrwl 也拥有 NX 构建系统。我使用 Lerna 在一组项目中运行脚本，并更好地了解控制台输出。
\n如果您\xe2\x80\x99决定走monorepo路线，我强烈建议您投入一些时间并采用构建系统。我使用过 NX 和 Bazel，事实证明它们在不同场景下非常有用。对于包含大量 JS 项目的 monorepos，我毫无疑问会使用 NX。它有非常好的文档，并提供了无数的工具来加快我们的工作。使用 NX，所有依赖项都保留在项目的根目录中，但这没关系，因为我们有一个内部依赖关系图，它允许我们生成一个包含一个 monorepo 项目所需的所有依赖项的 package.json。
\n| 归档时间： |
|
| 查看次数： |
1842 次 |
| 最近记录： |