问题描述
我的纱线工作区目录结构如下：
monorepo/
└── packages/
├── core/
│ └── package.json
└── distro/
└── package.json
distro 使用来自 core 的代码，要求通过工作空间访问 core （我相信它是在后台使用npm link）。核心或发行版都不会发布；但是 distro 确实需要在不同的计算机上“构建”（其某些依赖项使用make命令来构建正确的体系结构）。核心是不可知的。
在我想将 distro 推送到（例如）用于构建的IOT机器的情况下，由于IOT机器是纱线工作区，因此它不再具有访问packages/core的权限。我可以推送整个monorepo，但是然后我迫使机器 1）存储一些将不使用的代码（monorepo中还有其他软件包）和 2）强制机器在npm上使用纱线。
类似地，我不能在本地构建 distro ，然后再进行推送，因为（如前所述）某些外部依赖项确实需要针对特定体系结构进行构建。
除了更普遍的问题“您将如何进行管理？”之外，我想还有一个更直接的问题；是否有一个构建系统可以让我将一些本地依赖项捆绑到一个构建中（ distro + core ），同时又足够灵活，可以根据需要安装外部依赖项从物联网机器？有兴趣知道其他人将如何进行管理吗？
解决方法
我意识到这不是您要寻找的答案，但您实际上不应该将存储库中的单个工作空间拆开以进行独立构建。
当Monorepo由Yarn Workspaces管理时，每个包（也称为“工作区”）不再是独立的。例如，您将在存储库的顶层拥有单个yarn.lock。当您在没有周围环境的情况下构建项目时，该锁定文件不可用于构建工具，并且依赖项树是从package.json重新创建的，可能会导致每次构建的依赖项版本不同。
根据评论中的讨论进行更新，以使将来的读者更容易理解-
Yarn Workspaces可能是当今您可以使用单个工具管理monorepo的最佳选择。但是，它主要假设您是从更小，更易管理的部分（“工作区”）构建单个系统。对于部署了云的系统而言，通常情况是这样，您始终将其整体部署，但可能无法完全满足您对分布式系统的需求，在分布式系统中，您分别对各个版本（“程序包”）进行发行和发布。 NPM + Lerna的组合可能更适合此用例。
不幸的是，我在Lerna上没有足够的实践经验，不能给出一个很好的例子。我将按照以下思路进行研究-确保每个程序包都有自己的锁定文件（这意味着没有Yarn），构建core并将其作为带有时间戳的版本发布到某些内部npm存储库（GPR，Artifactory，verdaccio等），然后将distro拉到目标计算机，将core依赖项升级到发布的版本，执行npm install并运行测试。