2023年7月7日发(作者：)

ts引⼊js⽂件_前端⼯具类项⽬规范化-使⽤TS 当我们在开发维护⼀些⼯具类项⽬的时候，随着功能的丰富以及维护⼈员的变更，会导致代码的可持续维护性下降，因此需要⼀些其他⼯具来帮我们提⾼代码质量，减少⼀些不必要的错误。本篇我们来介绍使⽤TS来做⼀些事情。什么是TSTypeScript 是微软开发⼀款开源的编程语⾔，本质上是向 JavaScript 增加静态类型系统。它是 JavaScript 的超集，所有现有的JavaScript 都可以不加改变就在其中使⽤。它是为⼤型软件开发⽽设计的，它最终编译产⽣ JavaScript，所以可以运⾏在浏览器、 等等的运⾏时环境。TS能做什么⾸先TS的定位是静态类型语⾔，⽽不是类型检查器（对⽐flow）。从开发⼯具提供的能⼒看也不仅仅是类型检查，很直观的就是Intellisense over Compilation Error，当⼀段代码有问题（⽐如少写了字母）时，写完马上就会有红⾊波浪线提⽰，⽽不是等到编译的时候才告诉你哪⼀⾏有问题。因此使⽤TS提供的类型系统+静态分析检查+智能感知/提⽰，使⼤规模的应⽤代码质量更⾼，运⾏时bug更少，更⽅便维护。对⽐js有哪些优势开发效率虽然需要多写⼀些类型定义代码，但TS在WebStorm等IDE下可以做到智能提⽰，智能感知bug，同时我们项⽬常⽤的⼀些第三⽅类库框架都有TS类型声明（@types管理），我们也可以给那些没有TS类型声明的稳定模块写声明⽂件，这在团队协作项⽬中可以提升整体的开发效率。可维护性长期迭代维护的项⽬开发和维护的成员会有很多，⼈员的不稳定性和团队成员⽔平的差异的差异性，以及软件本⾝具有熵的特质，导致长期迭代维护的项⽬总会遇到可维护性逐渐降低的问题。⽽有了强类型约束和静态检查，以及智能IDE的帮助下，可以降低软件腐化的速度，提升可维护性。并且如果在重构代码时，强类型和静态类型检查会帮上⼤忙，⼀定程度上减少重构代价。（⼤家开发维护起来更安全、放⼼）。线上运⾏质量我们现在的⼯具类项⽬很多bug都是由于⼀些调⽤⽅和被调⽤⽅的数据格式不匹配引起的。TS可以在编译期进⾏静态检查，可以在编写调试代码时就发现这些问题，并且IDE可以智能纠错，编码时就能提前感知bug的存在，我们的线上运⾏时质量会更为稳定可控。Flow、babel、tsc类型检查flow⽤来做类型检查，⽐如vue就是⽤的flow，但是flow也有很多问题：1. ⽆⽤的错误信息⽐如 Incompatible instantiation for T， T 是⼀个类型变量，但是你并不能迅速找到这个错误在哪⾥。2.运⾏困难运⾏ Flow是需要⼀定成本的。对于Mac ⽤户来说⾮常幸运，通过 homebrew 可以安装预制的⼆进制包。但如果你需要⾃⼰编译它，你就先得建⽴⼀套 OCaml 开发环境。代码处理babel相⽐于tsc，⾸先定位是不同的，babel是⼀种js预处理⼯具，理论上说完全可以实现对ts的预处理，但是tsc对ts处理会更加精细。当然tsc 的功能没有 babel 多，扩展性也没有 babel 强。项⽬的应⽤tsconfig配置ts配置⽂件有很多配置项，但是对于我们开发node⼯具来说其实⽤到的并不多，我们只需要关注模块化，编译路径和输出路径即可。关于模块化，我们希望输出的是commonjs规范的，⾄于最终是es5/es6或是其他，因⼈⽽异，我们需要配置的就是："compilerOptions": { "module": "commonjs", "esModuleInterop": true, "target": "es5", "moduleResolution": "node"}编译路径和输出路径，这⾥跟webpack类似，当然这⾥的编译路径是指定tsc编译哪些⽬录下的ts⽂件，否则编译会因为内容太多⽽报错。"compilerOptions": { "outDir": "lib" //输出路径 }, //编译⽬录 "include": [ "src/**/*" ],当然我们还可能会指定types的路径"paths": { "*": [ "node_modules/*", "src/types/*" ] }npm包的types对于多数的npm包来说都可以通过安装@types/xxx来解决，⽐如node我们就可以安装@types/node，当然也有⼀些@types并没有做管理，那就需要我们⾃⼰来写⼀下。举个例⼦，webpack处理html相关会⽤到⼀个插件“html-webpack-plugin”，它是作为⼀个模块来使⽤，那么只需要以下声明即可declare module 'html-webpack-plugin';当然你可能会⽤到某些UMD的包（既可以当模块⼜可以作为全局变量使⽤）：declare namespace UMD{ //可以定义⼀些其他东西}interface（接⼝）⽐如我们有些⽅法需要修改⼀些参数，使⽤TypeScript 之后，把数据对应的 interface 改掉，然后重新编译⼀次，把编译失败的地⽅全部改掉就好了。对于builder-webpack4来说很多⽅法的参数都较为复杂，⽐如我们⽣成构建配置⽂件的时候，webpack的配置⽼多了，⾃然是需要写个interface来控制，但是问题是如果别的模块调⽤这个⽅法⼜得重写⼀次？不⽤的，只要吧interface当作模块⼀样导出即可（当然你也可以把这些写到中，然后引⼊到对应的⽂件）。export interface xxx{ [propName: string]: any}静态类型检查当我们开始盲写代码的时候，总会不可避免的有些⼩失误，那么利⽤IDE配合ts提供的⼯具就可以帮我们提前发现⼀些问题；在编译调试中同样可以发现⼀些未触及的点。设置图⽚的编译规则我们在调⽤⽅法的时候就知道这个⽅法需要哪些参数，当然如果类型写错了就⽴马会有红⾊波浪线标注出来（格外的扎眼）。传⼊错误的参数代码质量的提升作为⼀种弱类型语⾔，js开发⼀些⼤型/持续维护项⽬的时候，经常会让⼈体验什么是“开发⼀时爽，重构⽕葬场”（ts在Q你了）。其他注意点对于模块的导出export default builderWebpack4;这个玩意编译出来其实是这样⼦的t = builderWebpack4;但是对于调⽤者来说并不能直接⽤，我们想要的是s = builderWebpack4;所以源码中多加个指定就好了s = t;当然对于项⽬内部间模块调⽤是不需要的，tsc构建会⽣成相关的hackvar __importDefault = (this && this.__importDefault) || function (mod) { return (mod && mod.__esModule) ? mod : { "default": mod };};Property(exports, "__esModule", { value: true });var webpack_1 = __importDefault(require("webpack"));什么时候需要⽤⼤型项⽬项⽬越⼤，越难以维护，因此对于多⼈写协作的⼤型项⽬有必要使⽤ts来提⾼代码质量。持续维护的项⽬对于⼀些长久运⾏的项⽬，既要保证它的稳定运⾏，⼜要保证项⽬交接便捷（可维护性），使⽤ts是⽬前来看最好选择。⼯具类项⽬使⽤nodejs/js写⼀些前端⼯具或者库的时候，同样是需要关注以上两点内容，⽽且⼯具类的项⽬影响范围较⼤，在开发维护中要更加谨慎，那么使⽤ts帮我们尽量减少⼀些低级错误是很有必要的。写在最后