按需引入Angular组件库模块时如何避免引入未使用第三方依赖

这个需求100%具备可行性，多次尝试失败核心是组件库的打包发布规范不符合Angular生态要求，和Tree Shaking机制本身没有必然关联。

首先纠正一个认知偏差：

Tree Shaking仅在buildOptimizer、optimization配置为true时生效，开发环境无法生效，这个结论仅适用于整包全量导出、未做入口拆分的组件库。只要按照Angular Package Format（APF）规范做入口拆分，消费方无需等待摇树优化环节，在开发编译阶段就可以避开无关依赖的检查。

具体落地配置方式如下：

• 放弃从组件库根入口public-api.ts全量导出所有模块的做法，使用ng-packagr为每个独立功能模块配置次级入口（Secondary Entry Points）：
  • 对无@angular/material、date-fns依赖的通用模块（如基础按钮、布局、表单输入组件等），单独配置独立次级入口，例如组件库包名为@company/ng-ui时，这类模块的导入路径设为@company/ng-ui/button、@company/ng-ui/layout，这类入口的代码中绝对不能引入任何和两个第三方包相关的符号
  • 对依赖@angular/material、date-fns的模块（如日期选择器、Material风格弹窗等），同样配置独立次级入口，例如@company/ng-ui/date-picker、@company/ng-ui/mat-dialog，仅在这类次级入口的配置中声明对两个第三方包的peer依赖，只有引入这些模块的项目才需要安装对应依赖
• 调整依赖声明规则：不要把@angular/material、date-fns写在组件库根目录package.json的dependencies或peerDependencies中，仅在对应带依赖的次级入口的配置里声明相关peer依赖，避免包管理器强制所有消费方安装无关依赖
• 打包时开启Ivy部分编译（compilationMode: 'partial'），不要使用已废弃的View Engine编译模式，避免跨模块依赖分析出现偏差，把无关依赖的检查逻辑带进来

之前尝试失败的常见踩坑点：

• 根入口文件全量导出了所有模块（包括带第三方依赖的模块）：这种情况下Angular编译器解析根入口时会顺着import链扫描所有依赖，哪怕业务代码只用到了无依赖的基础模块，只要根入口导出了带第三方依赖的模块，编译阶段就会报依赖缺失错误，和摇树开不开没有关系
• 次级入口之间存在不合理的交叉引用：比如无依赖的基础模块意外引入了依赖Material模块的工具函数，会导致依赖链被污染，引入基础模块时也会触发第三方依赖检查
• 错误将第三方依赖打包进了组件库产物：ng-packagr配置错误时会把@angular/material、date-fns的代码直接打进无依赖模块的产物里，既增加体积，也可能引发版本冲突

最后补充：只要入口拆分和依赖配置符合规范，开发环境下ng serve哪怕关闭所有优化选项，也不会要求消费方安装未使用的第三方依赖——因为编译器根本不会解析业务代码没有import的次级入口内容。生产环境开启摇树只是做额外的产物体积裁剪，和「能不能不装无关依赖」是两个完全独立的问题，不要混淆两者的作用边界。

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