小编McF*_*iez的帖子

我一直在查看 BullMQ 的文档：

https://github.com/taskforcesh/bullmq

https://docs.bullmq.io/what-is-bullmq

我在其比较图表中注意到它不包含 RabbitMQ 或 NATS Streaming 等项目。BullMQ 似乎是一种跨一台或多台服务器处理简单“作业”的解决方案。

为什么 BullMQ 比其他消息队列实现更适合简单的“工作”？我试图了解什么时候选择一种实现比另一种实现更有意义。

在 3.9.0 中，Maven 引入了远程存储库过滤。

从理论上讲，这听起来很棒：

\n

想象一下，您可以指示 Maven 哪个存储库可以包含什么工件？Maven 可以通过受控方式直接到达所需的远程存储库，而不是在远程存储库中以 \xe2\x80\x9cordered 循环\xe2\x80\x9d 搜索工件。

\n

直到你看到细则：

\n

Maven Central (MC) 存储库在这方面很特别，因为 Maven 将始终尝试从这里获取东西，因为您的构建、插件、插件依赖项、扩展等通常来自这里。虽然您可以过滤 MC，但过滤 MC 通常是一个坏主意（过滤，如 \xe2\x80\x9c 限制来自它的内容 \xe2\x80\x9d）。另一方面，MC 本身提供了帮助来防止请求泄漏给它（请参阅 \xe2\x80\x9cprefixes\xe2\x80\x9d 过滤器）。

\n

\n

因此，最常见的是限制 \xe2\x80\x9c 可以从 MC 获取 \xe2\x80\x9d 的内容是一个坏主意，它可以完成，但要以非常非常谨慎的方式进行，否则您的构建将面临风险。RRF 不区分工件的 \xe2\x80\x9ccontext\xe2\x80\x9d ，它只是通过（工件，remoteRepository）对过滤掉它们，并且通过限制 MC，您可以轻松进入破坏构建的状态（因为插件取决于过滤的工件）。

\n

我的个人存储库中有一堆罐子。即使它们在我的 ~/.m2 中被明确标记为这样：

#NOTE: This is a Maven Resolver internal implementation file, its format can be \nchanged without prior notice.\n#Fri May 12 21:15:32 PDT 2023\nmy-commons-2.1.0.pom>personal=\nmy-commons-2.1.0.jar>personal=\n

我一直试图找到这个问题的明确答案，但不幸的是我一直未能找到。有两个类似的问题涉及这个主题，

开发人员是否应该能够在其开发环境中从 lerna monorepo 创建 docker 工件？

如何在 lerna monorepo 中构建 docker 镜像而不发布

但他们没有明确回答，我认为需要添加更多背景才能得到更清晰的答案。

我正在使用 Next.js 和几个 Express 服务器建立一个业余爱好项目。我正在构建一组微服务，并且它们之间将有一个可以共享的公共资源。由于这是一个业余爱好项目，因此将所有这些都存在于单个 git 存储库中是有意义的。同样，作为一个业余爱好项目，不必将任何包发布到像 NPM 这样的注册表也是有意义的。

让我们想象一个类似于 lerna（JS monorepo 工具）文档展示的结构：

my-lerna-repo/
  package.json
  packages/
    package-1/
      package.json
    package-2/
      package.json

使用像 Lerna 这样的工具，您可以拥有一个commons依赖的包，并让其他包引用它。Lerna 将提升这个commons包并简单地在包的node_modules.

这在开发时是有意义的，但是当您容器化服务时，这在生产中如何工作呢？例如，如果我们Dockerfile为每个服务创建一个并将其放入 Kubernetes 集群中，容器将会失败，因为commons依赖项不存在——它只是一个符号链接。

我研究过勒纳的“复制”论点，但不存在这样的论点。我知道还有其他 JS monorepo 工具（例如 Rush），但我知道 Lerna 是最受欢迎的。

如何解决容器化 monorepo 依赖包而不发布它们的问题？