从顶层向下将传统命名空间代码迁移为ES模块

1. 部分仓库无合适入口文件，需手动罗列大量文件 #

• 给每个仓库添加入口文件（比如index.ts），在入口文件中统一导出仓库内需要对外暴露的成员，示例：

  // 仓库B的index.ts
  export { ClassB1 } from './src/classB1';
  export { ClassB2 } from './src/classB2';
  

• 这样Webpack的入口只需指向该index.ts，无需手动罗列所有文件；后续其他仓库导入时，也可以直接通过import { ClassB1 } from '@your-org/repo-b'的方式调用，更简洁规范。

2. TS2305错误：模块无导出成员'test' #

• 先检查打包后的JS文件是否正确导出了test成员，确认Webpack配置中output.library.type是否设为合适的模块模式（比如'module'或'commonjs'，匹配你的模块系统）。
• 不要手动复制打包后的JS到node_modules，应该给每个仓库发布为npm包（私有仓库或本地npm link均可），同时在仓库的package.json中指定types字段指向类型声明文件（比如"types": "./dist/index.d.ts"），让TypeScript自动识别类型。
• 本地开发时用npm link把依赖仓库链接到当前仓库的node_modules，避免手动复制导致的类型不匹配。

3. 导入JS文件能否获得类型支持 #

• 可以实现，需满足以下条件：
  • 每个仓库编译时生成对应的类型声明文件（d.ts），在tsconfig.json中开启"declaration": true和"declarationMap": true。
  • 在仓库的package.json中配置types或typings字段，指向生成的类型声明入口文件。
  • 如果导入未发布的本地JS文件，可以手动创建对应的d.ts文件，或用/// <reference path="./xxx.d.ts" />引入类型声明。

4. 是否需要将HTML中的script标签改为type=module #

• 分两种情况判断：
  • 如果最终打包输出的是ES模块（Webpack的output.library.type设为'module'），则script标签必须添加type="module"，现代浏览器均支持该模式，如需兼容旧版浏览器可添加降级方案。
  • 如果打包输出的是UMD或IIFE格式（兼容传统script加载），则不需要修改，但这种方式不利于后续完全过渡到ES模块，建议优先选择ES模块格式配合type="module"。

5. 使用npm引入外部模块时是否需配置Webpack的externals #

• 取决于你的需求：
  • 如果希望外部模块（如第三方库）不被打包进bundle，而是在运行时通过script标签加载，需要配置externals，示例：

    // webpack.config.js
    externals: {
      lodash: '_'
    }
    

  • 如果希望把外部模块打包进bundle，则无需配置externals，Webpack会自动处理解析。
• 对于自己的内部仓库（A、B、C等），若已发布为npm包，不需要配置externals，Webpack会正常解析导入。

6. 先迁移顶层仓库，最后统一改造基础仓库并修正导入的方案是否可行 #

• 可行，但需注意过渡阶段的兼容处理：
  • 改造顶层仓库时，暂时保留对基础仓库命名空间的兼容层，示例：

    // E仓库过渡阶段代码
    // 先兼容旧的命名空间
    export const Test = window.A.Namespace.Test;
    // 后续替换为ES模块导入
    // import { Test } from '@your-org/repo-a';
    

  • 所有顶层仓库改造完成后，再集中改造基础仓库A，此时只需把顶层仓库的兼容代码替换为正式的ES模块导入即可。
  • 过渡期间可临时用@ts-ignore忽略类型错误，但要尽快替换，避免积累技术债务。

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