创建一个从 3rd 方库提供服务的 Angular 共享库和模块是一个好习惯吗？

如何解决创建一个从 3rd 方库提供服务的 Angular 共享库和模块是一个好习惯吗？

我正在开发一个 Angular 项目，该项目将包含两个应用程序和一个共享服务模块以及可能的共享功能模块。定义一个“核心”模块似乎是一种常见的做法，该模块导出 CommonModule 和 FormsModule 以及应用程序和功能模块所需的其他通用组件、管道和指令。 Core 模块将它们导出，使它们都可以从一个“Core”模块中使用。我想知道对来自 3rd 方库（例如日志服务）的服务/提供者做同样的事情是否也有意义。似乎我可以在我的 Core 模块中编写一个 forRoot() 函数，该函数从我的应用程序依赖的第 3 方库中返回所有提供程序，作为“冒泡”的一种方式。然后，每个应用程序模块只需导入 CoreModule.forRoot() 作为将一组通用依赖项（组件、管道、指令和服务）导入应用程序的方法。可以配置一些 3rd 方库，因此 CoreModule.forRoot() 可以接受一个配置对象来配置各种 3rd 方模块。

解决方法

我尝试了这个，发现不允许从您自己的库中的第 3 方库中“冒泡”提供程序，然后将您自己的库导入到应用程序中。我尝试的方法是在共享库中编写一个 forRoot() 函数，该函数又调用 LoggerModule.forRoot()：

static forRoot(config: LoggerConfig): any[] {
  return [
    MyCoreModule,LoggerModule.forRoot(config),];
}

编译器报告错误，指出无法静态评估 forRoot() 函数。所以......我想我最初的问题的答案是：不，你不应该尝试从 3rd Party 库中冒泡提供者。相反，应用程序模块应该直接导入第 3 方模块。就我而言，这是：

  imports: [
    LoggerModule.forRoot({
      level: NgxLoggerLevel.DEBUG,}),]

最初的目标是将第 3 方库和模块隐藏在一个“核心”库中，以创建一种“平台”库。但这有其自身的缺点。