React应用中同时使用.tsx和.js文件是否属于不良编码约定？

这种在纯JS React项目中单独给部分组件改用TS开发的做法，是官方推荐的低风险迁移方案，绝大多数场景下不会引发故障，只有少量配置和边界情况需要留意。

可行性基础 #

React 生态本身对.js/.jsx 和 .ts/.tsx 混写做了完整兼容，只要你的构建工具配置正确即可正常运行：

• 若使用 Create React App 脚手架：默认内置TS支持，只需安装typescript、@types/react、@types/react-dom三个依赖，直接将目标组件后缀改为.tsx即可生效，无需额外修改配置
• 若使用自研webpack/vite构建配置：只需给对应编译loader新增.ts/.tsx后缀匹配规则，在tsconfig.json中开启allowJs: true，即可兼容原有JS文件，不需要全量改造整个项目
• 其他构建工具只要支持TS编译，均可参考官方文档添加少量配置实现混写

可能遇到的小问题 #

整体没有致命风险，但少数细节处理不当可能会引发编译报错：

• 无类型组件引入报错：TS组件引入未加类型声明的原有JS组件时，会触发隐式any报错，要么给对应JS组件补充简易.d.ts类型声明，要么临时关闭tsconfig中的noImplicitAny校验规则即可解决
• 特殊导出导入规则冲突：JS和TS的默认导出、命名导出规则完全一致，常规用法不会有问题，只有原有JS组件用到非常冷门的动态导出/导入写法时，才需要少量调整或者加as any类型断言兼容
• 严格模式冲突：如果首次接入TS就开启全量严格校验规则，可能会和原有JS代码的松散写法产生大量校验冲突，建议初期只对新写的TS组件开启基础校验，后续逐步提严格度即可
• 注意TS仅做编译期校验：TS的类型校验只在编译阶段生效，编译后产物和普通JS完全一致，不会影响原有项目的运行逻辑，哪怕TS代码有类型告警，只要编译通过，运行效果和手写JS完全相同

实操建议 #

如果要落地部分组件用TS开发的方案，建议按以下优先级推进，降低风险：

• 优先改造新增的业务组件，不要上来就修改底层公共组件，避免影响线上已有逻辑
• 公共组件如果要改TS，建议先保留原有JS版本做兼容，全量验证无问题后再完全替换
• 初期不用追求全量类型覆盖，先给组件Props、函数入参出参补核心类型即可，大幅降低迁移成本

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