【问题标题】:Angular 9 library with subentry points circular dependency具有子入口点循环依赖的Angular 9库
【发布时间】:2020-07-08 05:16:35
【问题描述】:

我有一个关于 Angular 库辅助入口点设置的非常具体的问题。我真的不明白如何设置它以使其在它们相互依赖时工作,包括主要入口点。我已经阅读了 ng-packagr 的文档以及很多问题和堆栈问题,但没有找到真正好的答案。问题是我想把我们庞大的内部库分解成更小的部分,这样对于不需要所有东西的应用程序的导入和依赖项就会变得更小。

这就是我想要达到的目标:

  • 主库 @my/my-lib
  • 二级路径@my/my-lib/functions
  • 二级路径@my/my-lib/constants
  • 二级路径@my/my-lib/lang
  • 二级路径@my/my-lib/broker
  • 二级路径@my/my-lib/signalr
  • 二级路径@my/my-lib/sso
  • 二级路径@my/my-lib/types

这就是文件夹结构:

projects\my-lib
-- constants\
---- ...
---- package.json
---- public_api.ts
-- functions\
---- ...
---- package.json
---- public_api.ts
-- lang
---- ...
---- package.json
---- public_api.ts
-- broker
---- ...
---- package.json
---- public_api.ts
-- signalr
---- ...
---- package.json
---- public_api.ts
-- sso
---- ...
---- package.json
---- public_api.ts
-- src <-- the main entry point, as setup from the ng g library
---- lib
------ modules <-- the old ones from where i want to source parts out in secondary paths
-------- auth
-------- config
-------- footer
-------- header
-------- log
-------- state
-------- ...
---- public_api.ts
-- ng-package.json <-- main entry point
-- package.json <-- main entry point

现在这是我的问题:

前两个常量和函数按预期工作,因为它们不依赖任何东西。

现在,当我想从主 @my/my-lib 中的 @my/my-lib/lang 导入某些内容并反向时,我会收到一个循环依赖警告。这首先对我来说是合乎逻辑的,因为 ng-packagr 不知道先构建哪个。

到目前为止,我读到的是辅助入口点每次都首先构建,当我没有从 @my/my-lib/lang@my/my-lib 内部的服务的依赖关系时,这将完美运行,所以我该如何设置这个我可以从@my/my-lib 导入@my/my-lib/lang 中的东西并反向吗?

【问题讨论】:

  • 循环依赖很可能发生在你的场景中。您需要做的是在@my/my-lib 中导入@my/my-lib/lang。然后,如果您需要任何其他库中的某些功能,则直接将其导入 @my/my-lib/lang,而不是导入 @my/my-lib。
  • 你尝试过 peerDependencies 吗?

标签: angular angular-library ng-packagr


【解决方案1】:

根据我的经验,如果您使用 Angular CLI,次要入口点是在主入口点之后构建的。您可以拥有的唯一可能引用是从辅助入口点引用主库。您只能在一个方向上再次在辅助入口点之间进行引用。在构建期间,引用被解析并确定辅助入口点的构建顺序,因此它们按引用顺序构建。

对于您的示例,您唯一可以做的就是从 @my/my-lib 导入内容到 @my/my-lib/lang 中,然后在 @my/my-lib/lang 中导入例如 @my/my-lib/types

导入应该是库而不是文件。

import { MainLibClass } from '@my/my-lib';
import { MyType} from '@my/my-lib/types';

辅助入口点就像主库中的另一个独立库,建立在它之上或提供一些连接到主入口点的独立功能。这就是为什么像图书馆一样,你永远无法在两个方向都有参考。

更多我不能说,因为你没有提供任何信息,为什么你需要参考来双向。根据我从您的设计中看到的情况,最好为您现在已创建辅助入口点的每个部分创建单独的库。

【讨论】:

  • 好吧,我不想重新设计实际的主库结构。我只想将一些特定部分外包给次要入口点,依赖项只加载次要入口点,例如当我有类似 oauth2 或 signalr 的东西时。让我给你一个简单的例子。我有一个服务MyLoggingService。它位于主库中。但是这个服务是整个库的核心依赖,包括一些辅助入口点。当我说我必须将这部分也移动到它自己的次要入口点,如@my/my-lib/logging 时,对吗?
  • 不,您可以从辅助入口点内的主库中引用服务,正如我在答案中描述的那样。您无需将其移动到辅助入口点。自从你接受了我的回答,我猜你已经明白了。
  • 不,我给了你赏金,因为你的答案是唯一且详细的,但不是解决方案。我从主库导入时的问题导致循环依赖,因为辅助入口点将由主库导入。我必须导入MyLoggingService from @my/my-lib withing MyLangugeService from @my/my-lib/lang,但完整的@my/my-lib/lang@my/my-lib 中某些模块的依赖项,例如用于翻译的MyLayoutsModule。这让我想到,我必须将所有交叉依赖项移动到它们自己的辅助入口点。
  • 至少对我来说,您不能在主库中导入辅助入口点,即使您没有双向参考,这也根本不起作用。您需要将所有常用的东西放在主库中,然后在辅助入口点中使用它们。可能需要语言服务的主库中的功能也应该是辅助入口点,然后您可以在那里引用它。我需要看看你的设计才能说出更多可以做的事情。
  • 我上面的图片告诉你实际的设计。一切都在src/lib/modules/my-feature-module 之下,它们有时相互依赖,尤其是来自src/lib/modules/config/*src/lib/modules/broker/*src/lib/modules/state/* 等的代码部分。那是我想拆分一些部分的旧结构,以便像 @microsoft/signalrangular-oauth2-oidc 这样的第三方依赖项仅在需要时加载,而不是整个库。
猜你喜欢
  • 1970-01-01
  • 2020-05-29
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2023-03-04
相关资源
最近更新 更多