Angular库按需依赖问题：仅导入单个模块无需安装全部peer依赖

这是Angular库开发里很常见的场景——当你的根模块一次性打包了所有功能模块时，不管用户用不用，Angular都会加载所有模块并检查它们的peer依赖。下面给你几个可行的解决方案，按推荐程度排序：

1. 拆分模块入口，提供独立导入选项 #

这是最直接也最符合Angular最佳实践的方案：

• 不要在你的NgLibModule中同时导入并导出ModuleA和ModuleB，而是把ModuleA和ModuleB作为独立模块暴露给用户，NgLibModule只作为可选的全量导入入口。
• 修改库的public_api.ts，确保单独导出每个模块：

  // public_api.ts
  export * from './lib/module-a/module-a.module';
  export * from './lib/module-b/module-b.module';
  export * from './lib/ng-lib.module'; // 保留全量导入选项
  

• 用户如果只需要ModuleA，可以直接导入它，完全不用碰NgLibModule：

  // 用户的AppModule
  import { NgModule } from '@angular/core';
  import { ModuleA } from 'your-lib';
  
  @NgModule({
    imports: [ModuleA]
  })
  export class AppModule { }
  

  此时Angular只会加载ModuleA，自然只会检查它的peer依赖package-a，不会触发ModuleB的依赖校验。

2. 用forRoot()实现条件性模块导入 #

如果你的场景需要保留NgLibModule作为统一入口，可以通过配置项动态决定是否加载某个模块：

• 修改NgLibModule，添加静态forRoot()方法，根据用户传入的配置决定是否导入ModuleB：

  @NgModule({
    imports: [ModuleA],
    exports: [ModuleA]
  })
  export class NgLibModule {
    static forRoot(config?: { enableModuleB?: boolean }): ModuleWithProviders<NgLibModule> {
      const additionalImports = config?.enableModuleB ? [ModuleB] : [];
      return {
        ngModule: NgLibModule,
        imports: [...additionalImports],
        exports: [...additionalImports]
      };
    }
  }
  

• 用户使用时，只需要在不需要ModuleB的情况下不传配置，或者明确设置enableModuleB: false：

  // 用户的AppModule
  import { NgModule } from '@angular/core';
  import { NgLibModule } from 'your-lib';
  
  @NgModule({
    imports: [NgLibModule.forRoot()] // 不加载ModuleB，无需安装package-b
  })
  export class AppModule { }
  

3. 动态导入依赖（兜底方案） #

如果上面两种方案都不适合你的场景，可以考虑让ModuleB的代码动态加载package-b，避免在模块初始化阶段就强制依赖：

• 在ModuleB的组件、服务或模块代码中，不要直接导入package-b的内容，而是用动态导入的方式：

  // ModuleB的某个服务
  import { Injectable } from '@angular/core';
  
  @Injectable()
  export class ModuleBService {
    async doSomethingWithPackageB() {
      try {
        const packageB = await import('package-b');
        // 使用packageB的功能
      } catch (error) {
        throw new Error('package-b is not installed. Please install it to use ModuleB features.');
      }
    }
  }
  

• 这种方式下，只有当用户实际使用ModuleB的功能时才会检查package-b是否存在，而不是在模块导入阶段就报错。不过这个方案不够优雅，因为peer依赖的初衷就是明确告知用户需要的依赖，所以只建议作为兜底。

总结一下，优先选择方案1——拆分独立模块入口，这不仅能解决依赖问题，还能让你的库更灵活，符合按需加载的现代前端开发理念。

内容的提问来源于stack exchange，提问作者sudharsan tk