独立Angular组件及svg-round-progressbar是否应依赖@angular/compiler？

好问题！这两个点刚好戳中了Angular库开发里依赖管理的核心细节，我来给你拆解清楚：

1. 独立Angular组件是否应当将@angular/compiler列为依赖项？ #

答案是绝对不应该——除非你的组件有极端特殊的动态编译需求（比如在运行时动态生成并编译组件，这种场景在常规业务组件里几乎不存在）。

原因很直白：

• 任何使用你这个独立组件的Angular项目，本身必然已经依赖@angular/compiler——不管是开发阶段用JIT编译调试，还是生产环境用AOT构建打包，Angular框架的核心工作流都离不开它。
• 如果把@angular/compiler列为直接依赖（dependencies字段），会导致包管理器安装组件时额外下载一份编译器，大概率会和宿主项目的编译器版本冲突，进而引发注入器不匹配、组件编译失败、运行时报错等一系列问题。
• 正确的姿势是把它放在peerDependencies中，明确告诉用户：“我的组件需要对应版本范围的@angular/compiler，但你的项目里肯定已经有了，记得版本匹配就行”。

2. 评审svg-round-progressbar的设计时，将@angular/compiler列为依赖项是否合理？ #

完全不合理，这类Angular核心依赖必须设为**对等依赖（peer dependencies）**而非直接依赖。

Angular组件库的官方最佳实践里，所有和Angular核心框架相关的包（比如@angular/core、@angular/common、@angular/compiler）都应该放在peerDependencies里：

• 这能避免重复安装框架包，大幅减少项目的依赖体积；
• 强制用户确保库的Angular版本和项目本身的版本对齐，从根源上规避版本不兼容的坑；
• 你可以看看Angular CLI生成的默认库模板，所有Angular核心依赖都是默认放在peerDependencies里的，这是官方认可的规范。

如果svg-round-progressbar目前把@angular/compiler放在dependencies里，这属于依赖管理的失误，建议提交issue或者PR修正这个问题，把它移到peerDependencies中，并指定合理的版本范围（比如^14.0.0 || ^15.0.0，匹配库实际支持的Angular版本）。

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