【问题标题】：Is it a good practice to create an Angular shared library and module that providers services from 3rd party libraries?创建一个从第三方库提供服务的 Angular 共享库和模块是一种好习惯吗？
【发布时间】：2021-05-02 16:56:56
【问题描述】：
我正在开发一个 Angular 项目，该项目将有两个应用程序和一个共享服务模块以及可能的共享功能模块。定义导出 CommonModule 和 FormsModule 以及应用程序和功能模块所需的其他常见组件、管道和指令的“核心”模块似乎是一种常见的做法。核心模块导出它们以使它们都可以从一个“核心”模块中使用。我想知道对来自 3rd 方库（例如日志服务）的服务/提供者做同样的事情是否也有意义。看来我可以在我的核心模块中编写一个 forRoot() 函数，该函数从我的应用程序所依赖的第 3 方库中返回所有提供程序，以作为“使它们起泡”的一种方式。然后，每个应用程序模块只需导入 CoreModule.forRoot() 作为将一组通用依赖项（组件、管道、指令和服务）导入应用程序的方法。可以配置一些第 3 方库，因此 CoreModule.forRoot() 可以接受配置对象来配置各种第 3 方模块。
【问题讨论】：
标签：
angular
module
shared
provider
【解决方案1】：
我尝试了这一点，发现不允许从您自己的库中的 3rd-party 库中“冒泡”提供程序，然后将您自己的库导入应用程序。我尝试的方法是在共享库中编写一个 forRoot() 函数，该函数又调用 LoggerModule.forRoot()：
static forRoot(config: LoggerConfig): any[] {
return [
MyCoreModule,
LoggerModule.forRoot(config),
];
}
编译器报告错误，指出无法静态评估 forRoot() 函数。所以......我想我最初的问题的答案是：不，你不应该尝试从 3rd 方库中冒泡提供程序。相反，应用程序模块应该直接导入第 3 方模块。在我的情况下是：
imports: [
LoggerModule.forRoot({
level: NgxLoggerLevel.DEBUG,
}),
]
最初的目标是将第 3 方库和模块隐藏在一个“核心”库中，以创建一种“平台”库。但这有其自身的缺点。