Angular TypeScript项目引入第三方JS文件的四种方式差异解析

让我帮你逐个拆解这四种引入方式，它们的差异本质上是不同Angular版本、构建工具（Webpack/Angular CLI）以及模块规范演变带来的结果：

方案A：CommonJS require 引入（2016年Angular2 + angular2-webpack-starter） #

• 代码示例：

  var Polyglot = require('../../../node_modules/node-polyglot/build/polyglot.min.js');
  

• 实现原理：这是CommonJS模块规范的典型写法，早期Webpack版本对CommonJS支持非常直接，通过require同步加载模块文件，并返回模块的导出值。2016年的Angular2项目构建链还深度兼容CommonJS（毕竟当时Node.js生态以CommonJS为主），所以这种写法能直接拿到Polyglot的构造函数。
• 为何现在失效：现代Angular项目（尤其是用Angular CLI或新版Webpack的）优先采用ES模块规范，很多库也转为ES模块输出，再加上新版构建工具对require的处理更严格，项目中通常不再配置CommonJS的宽松兼容，所以这种写法会触发编译错误。

方案B：ES模块默认导入（Angular4 + angular2-webpack-starter） #

• 代码示例：

  import Polyglot from '../../../node_modules/node-polyglot/build/polyglot.min.js';
  

• 实现原理：这是ES6+模块的默认导入写法。此时的polyglot.min.js已经被打包成支持ES模块的格式，或者Webpack通过配置将CommonJS模块转换为了ES模块兼容的形式，模块的默认导出就是Polyglot的构造函数。Angular4时期的Webpack构建链已经开始转向ES模块优先，所以这种默认导入能正确获取到目标构造函数。

方案C：命名空间导入（Angular5 + Angular CLI + Laravel嵌入） #

• 代码示例：

  import * as Polyglot from '../../../node_modules/node-polyglot/build/polyglot.min.js';
  

• 实现原理：这种写法是把整个模块的所有导出内容作为一个对象导入。出现这种需求的原因通常有两个：
  1. 该版本的polyglot.js的ES模块输出采用命名导出而非默认导出，或者打包后的模块没有正确设置默认导出；
  2. Angular CLI的构建链（基于Webpack）对模块解析更严格，要求明确区分默认导入和命名导入，用import * as可以覆盖所有导出情况，确保能拿到Polyglot构造函数（多数情况下可以直接通过Polyglot访问，部分场景下可能需要取Polyglot.default）。
• 适用场景：当模块的导出格式不明确，或者构建工具对默认导入的解析有严格限制时，这种写法的兼容性更好。

方案D：全局变量声明 + 脚本引入（旧Angular项目，类似jQuery引入方式） #

• 代码示例：

  import '../../../node_modules/node-polyglot/build/polyglot.min.js';
  declare var Polyglot: any;
  

• 实现原理：这种写法本质上是将polyglot.js作为全局脚本加载，而非模块导入。这里的import语句只是告诉Webpack把这个脚本打包到最终产物中，脚本执行后会在全局作用域（window对象）上挂载Polyglot变量。而declare var Polyglot: any;是给TypeScript做类型声明，避免编译时因为“找不到全局变量Polyglot”而报错。
• 适用场景：常用于那些没有适配ES模块/CommonJS的旧库（比如早期的jQuery），或者项目构建链对模块解析支持不佳的情况，直接依赖全局变量来使用库。

为什么不同项目中方案可行性不同？ #

核心原因是项目的Angular版本、构建工具版本、库的模块格式以及TypeScript配置这几个因素的差异：

1. 模块规范演变：从Angular2到Angular5，项目逐渐从CommonJS转向ES模块，构建工具对模块的解析规则也在迭代，所以早期的require（方案A）在新项目中不再适用；
2. 库的打包格式：polyglot.js不同版本的打包产物可能支持不同的模块规范（CommonJS/ES模块/UMD），不同构建工具对这些格式的处理逻辑不同，导致导入写法需要调整；
3. TypeScript配置：Angular CLI的tsconfig.json对模块解析有严格要求，比如module选项从CommonJS变为ESNext，会直接影响导入语句的有效性；
4. 构建工具配置：angular2-webpack-starter和Angular CLI的Webpack配置差异很大，前者更灵活兼容旧模块规范，后者更标准化，所以导入写法自然不同。

内容的提问来源于stack exchange，提问作者Kamil Kiełczewski