Angular将通用代码存于独立JS模块：咨询该方案的弊端

嘿，你的这个方案目前运行正常，但从长期维护、扩展以及Angular生态适配的角度来看，存在几个值得注意的问题：

1. 构建与路径的脆弱性 #

你的externallib文件夹在Angular项目的src目录之外，这会带来两个隐患：

• Angular的默认构建配置（比如angular.json里的文件包含/排除规则）没有把这个外部目录纳入管理，现在可能没问题，但升级Angular版本、启用AOT编译或调整优化选项时，很容易出现模块找不到、编译失败的情况。
• 每个SPA里的导入路径./../../externallib/Logger是硬编码的相对路径，如果某个项目调整了目录层级（比如新增子模块、移动AppModule位置），这个路径就会失效，需要手动修改，容易出错。

2. 缺少服务配置的灵活性 #

你直接在每个AppModule的providers数组里注册LoggerService，没法利用Angular的模块注入模式（比如forRoot()/forChild()）来动态配置服务。举个例子：

• 如果以后想给不同的SPA设置不同的日志级别（比如A项目用console.debug，B项目用console.info），你只能修改LoggerService的源码，没法在导入时传入配置参数，扩展性极差。

3. IDE与TypeScript支持受限 #

因为这个模块不在项目的src目录下，IDE（比如VS Code）的TypeScript语言服务可能无法正常解析它的类型定义，自动补全、跳转定义、错误提示这些便捷功能会失效，开发体验大打折扣。另外，如果开启了TypeScript严格模式（strict: true），你还需要手动修改tsconfig.json的include数组来包含这个外部目录，增加了配置复杂度。

4. 无法享受Angular的构建优化 #

Angular的构建工具（基于Webpack）会对src目录内的代码做tree-shaking、代码分割、压缩等优化，但外部目录的代码通常不会被纳入这些流程，导致最终打包体积变大。另外，**热模块替换（HMR）**功能也没法对这个外部文件夹的代码生效，修改LoggerService后需要重启整个应用，开发效率降低。

5. 测试流程复杂化 #

在单元测试或端到端测试中，你需要手动配置测试环境来导入这个外部模块，没法利用Angular测试工具（比如TestBed）的便捷方式来mock或替换LoggerService。比如想在测试中验证日志是否被调用，你得额外配置测试框架的模块解析规则，增加了测试的复杂度。

你当前的代码示例 #

Logger.ts（externallib文件夹）

import { Injectable } from '@angular/core';

@Injectable()
export class LoggerService {
  Log(message) {
    console.debug(message);
  }
}

app.module.ts

import { BrowserModule } from '@angular/platform-browser';
import { NgModule } from '@angular/core';
import { LoggerService } from './../../externallib/Logger'; //**This is my custom library**
import { AppComponent } from './app.component';

@NgModule({
  declarations: [
    AppComponent
  ],
  imports: [
    BrowserModule
  ],
  providers: [ LoggerService ],
  bootstrap: [AppComponent]
})
export class AppModule {
  constructor() { }
}

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