React + Typescript 工程化治理实践

Posted 2021-03-30 前端教程

每天前端开发干货第一时间送达！

https://github.com/ProtoTeam/blog/blob/master/201911/2.md

最近参与了一个 React + Typescript 组件项目，这个项目后期会开源，对代码的质量和工程化上有比较高的要求，因此需要进行工程化治理。通过这次工程化治理，笔者算是梳理清楚了一个 React + Typescript 第三方组件所需要的一些工程化方面的基础设施，在这里总结并分享给大家。

这次的工程化治理主要分以下几个方面：

• 静态检查：TypeScript + ESLint

• 开发体验：打包工具和 Mono-repo 管理

• 代码质量：测试

静态检查

TS 和 ESLint 这些工具本质上是对代码做静态检查，尽早发现隐藏的 bug。在 TS 出现之后，TS 有 ESLint 没有的类型检查，并且也具备 ESLint 具有的语法错误检查的能力，所以目前我们用 ESLint 主要是利用社区中数量庞大的 Lint 规则来对代码风格做一个规范，利用工具的方式去推行一些最佳实践。TS 则主要负责对代码语法和语义上的错误进行静态检查。另外，TS 本身是一个全新的语言，使用 TS 可以享受到一些 JS 没有的语言特性。

从 AnyScript 到 TypeScript

用 TS，一个很重要的区别就是有没有在配置中打开 strict 选项。如果没有的话，那其实你用的就是 AnyScript，在类型上基本没有约束，和 JS 没有太大的区别。如果是从 JS 迁移到 TS 的项目，这个选项应该关闭，因为老的 JS 代码没有写类型。但如果是全新的纯 TS 项目，strict 是一定要打开的。现在 CRA 这样的脚手架创建的项目也是默认开启了 strict 模式的。

打开 strict 模式其实很简单，难的是如何在 strict 模式下优雅的写 TS 代码。下面说说一些 strict 模式下的常见问题以及一些类型的技巧：

noImplicitAny

这个问题出现的最常见的场景就是函数的参数。如果习惯了写 JS，在写函数参数的时候很大可能会忘记写类型。虽然 TS 可以推断出函数的返回值类型，但不能推断出函数的参数类型。如果不写参数类型，那参数的类型默认就是 any，这个时候就会报 noImplictAny 的错误，因为 TS 的 strict 模式下不允许这种隐式 any 的存在。

解决这个问题，就要养成给函数参数加类型的习惯，并且不能直接加个显式的 any 就完事了