如何使用SystemJS处理Angular运行时加载模块的缺失外部依赖

1. 关于SystemJS.set('@angular/core', ...)的作用 #

这段代码的核心目标是保证主应用与外部加载模块共享同一份Angular核心实例，具体作用拆解：

• Angular框架本身对核心模块有强单例约束：如果外部模块单独加载一份独立的@angular/core实例，会直接引发依赖注入体系失效、组件渲染异常、变更检测逻辑错乱这类典型问题
• SystemJS.set的本质，是把主应用中已经编译、实例化完成的@angular/core对象，直接写入SystemJS的全局模块注册表
• 搭配SystemJS.newModule调用，是为了把原生ES Module格式的Angular核心模块，包装成符合SystemJS加载规范的模块结构
• 当外部UMD模块内部执行import '@angular/core'语句时，SystemJS会优先从全局注册表命中已存在的模块，不会重新发起网络请求拉取全新的Angular核心脚本，从根源上避免多实例冲突

2. 外部模块缺失第三方依赖（如示例中的xyz包）导致404的解决方案 #

出现404的逻辑很直白：你当前加载的外部UMD文件没有把xyz这类第三方依赖打包到产物里，当模块内部执行import { abc } from 'xyz'的导入逻辑时，SystemJS会默认按照根路径规则去http://localhost:4200/xyz找对应脚本——但主应用既没有把xyz的静态文件放到这个路径下，也没提前配置规则告诉SystemJS这个包实际该去哪找，自然就会返回404。
可以通过以下几种方式确保这类依赖正常加载：

• 提前在SystemJS初始化配置中添加模块映射规则
  在SystemJS启动的配置项中，通过map字段把所有外部模块可能用到的、主应用未内置的第三方包名，指向实际可访问的静态资源路径。比如针对示例中的xyz包，可配置map: { 'xyz': '/assets/vendor/xyz.umd.js' }。当SystemJS处理外部模块的导入语句时，会优先匹配映射规则，从指定路径拉取依赖脚本，拉取完成后存入全局模块注册表，后续其他模块导入同一包时可直接复用实例。
• 对高频公共依赖做提前全局注册
  如果主应用本身已经安装、打包了某类公共第三方包（比如rxjs、lodash这类通用工具库），可以参照注册@angular/core的方式，在应用初始化阶段直接通过SystemJS.set把这些模块写入全局注册表，外部模块导入时直接命中复用，无需重复拉取。
• 配置动态依赖拦截加载逻辑
  如果无法提前枚举所有外部模块可能用到的第三方依赖，可以重写SystemJS的resolve钩子：当检测到待加载的模块名未在全局注册表命中时，动态拼接内部静态服务器下的有效地址，再交给SystemJS执行加载。注意要做加载缓存，同一个第三方包仅发起一次网络请求即可。
• 备选方案：打包自包含的外部UMD产物
  如果不想维护复杂的映射规则，也可以在构建外部模块的UMD产物时，将所有依赖打包进UMD文件内部，让外部模块完全自包含。但这种方式存在明显短板：如果多个外部模块都依赖同一个第三方包，每个UMD都会重复打包一份相同的依赖代码，会增加整体加载的体积开销。

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