TypeScript已开启esModuleInterop仍无法正常导入flamelink模块怎么办

你遇到的两类报错核心来源是flamelink/app模块的类型定义通过export =语法导出整体可调用的工厂函数，而非带属性的命名空间对象：

• 写import * as flamelink from 'flamelink/app'触发的“命名空间导入不可调用”报错，就是因为这种导入方式拿到的模块对象不允许直接执行调用逻辑
• 写import flamelink from 'flamelink/app'触发的“默认导入需要esModuleInterop”报错，本质是编译时没有正确加载到你配置的esModuleInterop参数

哪怕全局开了esModuleInterop，只要存在多份tsconfig的配置作用域问题，也会出现配置不生效的情况。

• 第一步：核对tsconfig的实际生效范围
  从报错路径可以看到你的Firebase Function目录（functions）是嵌套在前端项目的client目录下的，这类嵌套项目通常会存在多份tsconfig.json的场景。你需要确认src/index.ts文件实际关联的tsconfig配置（也就是functions目录下的独立tsconfig）是否真的开启了esModuleInterop: true，避免把配置写在项目根目录、实际编译时用的是子目录下未开启该配置的tsconfig，导致配置失效。
• 第二步：使用TypeScript原生适配的导入写法
  针对采用export =导出的CommonJS模块，最稳妥、不会触发导入报错的写法是使用TypeScript原生的require导入语法：
  import flamelink = require('flamelink/app');
  这种写法完全匹配export =的模块导出规则，编译后在Firebase Function的Node.js CommonJS运行环境下可正常运行，不会出现“命名空间导入不可调用”的运行时问题。
• 第三步：适配ECMA风格默认导入的排查
  如果你坚持使用import flamelink from 'flamelink/app'的ECMA风格写法，需要确认：
  • 关联的tsconfig中esModuleInterop未被其他继承配置覆盖
  • 没有和module: commonjs的配置产生冲突
• 兜底方案：自定义类型声明绕开类型冲突
  如果核对完所有配置仍触发类型报错，可以在src目录下新建types/flamelink.d.ts文件，补充自定义类型声明绕开原包的类型定义冲突：

  declare module 'flamelink/app' {
    import type * as firebase from 'firebase/app';
    type FlamelinkConfig = {
      firebaseApp: firebase.App;
      env?: string;
    };
    const flamelink: (config: FlamelinkConfig) => any;
    export default flamelink;
  }
  

  该方案不影响实际运行时的模块加载，仅解决类型检查阶段的导入冲突。

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