create-react-app+TS项目抽离组件为NPM包后应用体积增大如何排查

1. TypeScript 辅助函数重复冗余 #

你当前PackageA的tsconfig.json未开启importHelpers配置，TS转译时会把__assign、__importStar、__rest这类通用辅助函数内联到每一个用到的文件中。而Create React App（以下简称CRA）处理项目内TS代码时，会默认复用统一的辅助函数，抽离为公共代码块。外部包中内联的辅助函数无法和项目内的辅助函数复用，就会产生重复代码，积少成多带来体积增量。

2. 二次压缩的效率损耗 #

你在发布PackageA时提前用UglifyJS做了压缩，而CRA构建TestApp时会对所有引入的代码再做一次统一压缩。已经被压缩过的代码结构会被打乱，第二次压缩的优化率会大幅下降，甚至会产生额外的冗余标记、短变量冲突带来的冗余代码，最终导致整体体积变大。

3. 依赖多版本共存 #

即使你把依赖从TestApp迁移到PackageA时用了完全相同的版本，也可能因为TestApp中其他间接依赖的版本约束，导致包管理器安装了多份相同的依赖。比如TestApp的某个其他依赖恰好也依赖了相同的包但版本范围不兼容，就会在PackageA的目录下单独安装一份依赖，造成重复打包。

4. 转译配置差异带来的代码冗余 #

你PackageA的tsconfig的target配置为ES6，而CRA会根据项目的browserslist配置做更细粒度的语法转译和优化，比如对JSX的额外编译优化、无用代码标记等，已经提前转译好的PackageA代码无法享受CRA的统一优化，可能导致相同逻辑的代码体积比CRA直接转译的更大。

5. 重导出逻辑的残留冗余 #

你新增的统一导出index.ts如果用了批量export *的写法，即使tree-shaking生效，部分打包工具处理外部ES模块的重导出逻辑时，可能会残留少量无法被清除的导出元数据代码，也会带来微小的体积增量。

• 优先用source-map-explorer工具分别分析抽离前后的外部依赖chunk产物，直接可视化定位新增体积对应的具体代码段，是效率最高的排查手段
• 临时关闭PackageA的预压缩逻辑，发布未压缩版本到私有源后重新构建TestApp，对比体积变化，如果体积下降则说明是二次压缩导致的问题，后续发布通用组件包无需提前做压缩，统一交给上层应用构建时压缩即可
• 在PackageA的tsconfig.json中新增"importHelpers": true配置，同时将tslib加入依赖，重新发布后测试体积变化，验证是否是TS辅助函数重复的问题
• 执行npm ls <包名>或者yarn list <包名>命令，逐一检查从TestApp迁移到PackageA的依赖，确认是否存在多版本共存的情况
• 对比CRA内置的TS转译配置和PackageA的TS配置差异，调整PackageA的转译配置和CRA对齐，验证体积变化
• 解压你发布的PackageA的npm包，检查实际包含的文件是否有冗余内容，比如意外打包的测试文件、sourceMap文件等

内容的提问来源于stack exchange，提问作者fast-reflexes