Project Reference优化TypeScript编译性能示例

目录
  • 引言
  • Project Reference
  • 总结

引言

TypeScript 给 JavaScript 添加了一套类型系统,可以在编译期间检查出类型错误,这增加了代码的健壮性,但也多了一个编译的过程。

ts 编译速度与项目规模有关,如果项目比较大,代码很多,那就需要编译很长一段时间。

有没有什么办法可以提升 tsc 编译的性能呢?

还真有,TypeScript 3.0 的时候实现了 Project Reference 的特性,就是用于优化编译和类型检查的性能的。

那 Project Reference 是干什么的呢?

Project Reference

想象这样一个场景。项目目录下有两个相对独立的模块 aaa 和 bbb

它们是用同一个 tsconfig.json 来配置编译方式的:

执行 tsc 就会编译所有 include 的文件到 dist 目录下:

假设 aaa 和 bbb 都很大,编译要很久,但是两者的关联还不是特别大。

aaa 模块下的变动基本和 bbb 模块下的没啥关系,但是 aaa 变了,bbb 也要重新编译一遍,bbb 变了 aaa 也要重新编译一遍,这就很没必要。

有的同学说,那在 aaa 和 bbb 下分别放一个 tsconfig.json,各自编译各自的不就行了?

这样是可以,但是这样就是多次编译了,比较麻烦。

能不能还是一次编译,但是对一些相对独立的模块做下缓存,不要跟随别的模块一起编译呢?

可以的,这就是 Project Reference 做的事情了。

在 aaa 和 bbb 下各自创建一个 tsconfig.json,放各自的编译配置。注意这里要加一个 composite: true,这是 Project Reference 需要的:

然后在根目录的 tsconfig.json 里加上一个 references 的配置,引入 aaa 和 bbb:

这样再执行 tsc --build 进行编译,你会发现编译结果多了 .d.ts 的声明,还多了 tsconfig.tsbuildinfo 的文件:

打开 tsconfig.tsbuildinfo 看一下,会发现它记录了编译了哪些文件,还记录了这些文件的 hash 值:

看到这里,你是不是就知道为啥它能实现缓存了?

没错,就是对比文件的 hash,当编译到这个 project 的时候,会对比下 hash 有没有变化,变了才去编译。没变的就直接跳过了。

而且,别的地方可能用到这个 project 的类型,所以需要生成 d.ts 声明文件,这就是为啥我们没有指定 declaration: true 的配置,但是编译产物里还是有 d.ts。其实这是 composite 选项做的,它设置了 Project Reference 需要的一些编译选项:

现在当你修改了 aaa 下某个模块的代码,重新编译的时候就不会编译 bbb 了,只会编译 aaa 下的那个模块。

这就是 Project Reference 的作用。

当然,这种编译模式和常规的编译模式不同,所以不是直接用 tsc 来编译,而是用 tsc --build 或者 tsc -b。

此外,Project Reference 还支持通过 prepend 指定编译顺序,比如给 bbb 添加 prepend: true,那么就会先编译 bbb,再编译当前项目,然后编译 aaa:

其实很容易想到,monorepo 里就可以用 Project Reference 来提升 tsc 的编译性能。因为 monorepo 下的多个 project 相互之间都比较独立,一个模块的改动一般不会影响另一个模块,所以编译的时候也应该各自做缓存。

总结

TypeScript 3.0 时实现了 Project Reference 来优化性能。

如果项目下有一些相对独立的模块,别的模块的变动不影响它,但是它却要跟着重新编译一次,这时就可以用 Project Reference 来优化了。

在独立的模块下添加 tsconfig.json,加上 composite 的编译选项,在入口的 tsconfig.json 里配置 references 引用这些独立的模块。然后执行 tsc --build 或者 tsc -b 来编译。

这时候就实现了编译和类型检查的性能优化。

原理是编译时会生成 tsconfig.tsbuildinfo 的文件,记录着编译的文件和它们的 hash,当再次编译的时候,如果文件 hash 没变,那就直接跳过,从而提升了编译速度。

这是 TypeScript 提供的编译性能优化机制,当项目比较大,tsc 执行的速度比较慢的时候,不妨尝试一下。

以上就是Project Reference优化TypeScript编译性能示例的详细内容,更多关于Project Reference优化tsc的资料请关注我们其它相关文章!

(0)

相关推荐

  • TypeScript Pinia实战分享(Vuex和Pinia对比梳理总结)

    目录 简介 安装 创建pinia并传递给vue实例 创建store state getters actions 在vue组件使用 获取state 获取getters 修改state 数据持久化 总结 简介 今天我们再来实战下官方推荐的新的vue状态管理工具Pinia. pinia 由 vue 团队中成员所开发的,因此也被认为是下一代的 vuex,即 vuex5.x,在 vue3 的项目中使用也是备受推崇.所以 pinia 的学习迫在眉睫. 下面我们正式开始pinia的学习吧. 安装 yarn a

  • 关于对TypeScript泛型参数的默认值理解

    目录 泛型简介 举个 举个 泛型参数的默认值——函数重载 泛型参数的默认值——正文 参考 泛型简介 软件工程中,我们不仅要创建一致的定义良好的 API,同时也要考虑可重用性. 组件不仅能够支持当前的数据类型,同时也能支持未来的数据类型,这在创建大型系统时为你提供了十分灵活的功能. 在像C# 和 Java 这样的语言中,可以使用 泛型 来创建可重用的组件,一个组件可以支持多种类型的数据. 这样用户就可以以自己的数据类型来使用组件. 举个 举个最简单的例子来理解泛型 function getVal(

  • typescript在node.js下使用别名(paths)无效的问题详解

    目录 背景 typescript不会对别名进行处理 另一个坑 调试tsconfig-paths 总结 背景 纯nodejs环境,直接使用tsc编译nodejs.源码目录是src,编译输出目录为bin.代码结构如下: src utils a.ts b.ts config … bin tsconfig.json 在其他深层次目录引用utils或者config下的文件时,总是要写一长串的'../../../../',还需要数数.这显然是不能接受的.用过webpack开发的小伙伴们,想想别名功能,typ

  • typescript+vite项目配置别名的方法实现

    我们为了省略冗长的路径,经常喜欢配置路径别名.但是在typescript下会遇到一些坑,比如导入路径不能以“.ts”扩展名结束,路径不识别等.下面我记录了我的处理方法. vite.config.js: export default defineConfig({   resolve: {     alias: {       '@': path.resolve(__dirname, 'src') // 配置别名     }   } }) 配置完之后,就可以在ide中使用别名了.但是这个时候我发现,

  • TypeScript利用TS封装Axios实战

    目录 简介 Axios几个常用类型 AxiosRequestConfig AxiosInstance AxiosStatic AxiosResponse AxiosError 基础封装 拦截器封装 常用方法封装 总结 简介 这是TypeScript实战的第三篇文章.前面两篇笔者分别介绍了在Vuex和Pinia中怎么使用TypeScript以及Vuex和Pinia的区别.今天我们再用TypeScript封装一遍Axios.希望能进一步巩固TypeScript的基础知识. Axios几个常用类型 在

  • Typescript中使用引用路径别名报错的解决方法

    在TS中引用路径别名提示找不到模块或者相应的声明 1.ts中使用路径别名报错 在react中通常路径别名都是在webpack的webpack.config.js文件中配置的,但是在引入了ts之后,webpack中的路径别名引用失效了此时我们需要在跟src文件同级目录的tsconfig.json文件中添加配置: 注意要在compilerOptions中添加(webpack中的路径也需要配置) "compilerOptions": { "target": "e

  • Project Reference优化TypeScript编译性能示例

    目录 引言 Project Reference 总结 引言 TypeScript 给 JavaScript 添加了一套类型系统,可以在编译期间检查出类型错误,这增加了代码的健壮性,但也多了一个编译的过程. ts 编译速度与项目规模有关,如果项目比较大,代码很多,那就需要编译很长一段时间. 有没有什么办法可以提升 tsc 编译的性能呢? 还真有,TypeScript 3.0 的时候实现了 Project Reference 的特性,就是用于优化编译和类型检查的性能的. 那 Project Refe

  • java实现1M图片压缩优化到100kb实现示例

    目录 引言 一.图像压缩 二.Java数字图像处理 三.图像压缩实战 四.其他开源库 五.一点点心声 引言 坦白从宽吧,我就是那个花了两天两夜把 1M 图片优化到 100kb 的家伙——王小二! 自从因为一篇报道登上热搜后,我差点抑郁,每天要靠 50 片安眠药才能入睡. 网络上曝光的那些关于一码通的消息,有真有假,我这里就不再澄清了.就说说我是怎么把图片从  1M 优化到 100kb 的故事吧. 是的,由于系统群体规模和访问规模的特殊性,每一行代码.每一张图片.每一个技术文档都反复核准,优化再优

  • web性能优化之javascript性能调优

    JavaScript 是一个比较完善的前端开发语言,在现今的 web 开发中应用非常广泛,尤其是对 Web 2.0 的应用.随着 Web 2.0 越来越流行的今天,我们会发现:在我们的 web 应用项目中,会有大量的 JavaScript 代码,并且以后会越来越多.JavaScript 作为一个解释执行的语言,以及它的单线程机制,决定了性能问题是 JavaScript 的软肋,也是 web 软件工程师们在写 JavaScript 需要高度重视的一个问题,尤其是针对 Web 2.0 的应用.绝大多

  • 详解优化iOS程序性能的25个方法

    1. 用ARC管理内存 ARC(Automatic ReferenceCounting, 自动引用计数)和iOS5一起发布,它避免了最常见的也就是经常是由于我们忘记释放内存所造成的内存泄露.它自动为你管理retain和release的过程,所以你就不必去手动干预了.忘掉代码段结尾的release简直像记得吃饭一样简单.而ARC会自动在底层为你做这些工作.除了帮你避免内存泄露,ARC还可以帮你提高性能,它能保证释放掉不再需要的对象的内存. 现在所有的iOS程序都用ARC了,这条可以忽略. 2. 在

  • my.ini优化mysql数据库性能的十个参数(推荐)

    今天刚好需要配置mysql 5.5.45,因为数据库量挺大的,所以必须优化,要不mysql真的不快. (1).max_connections: 允许的同时客户的数量.增加该值增加 mysqld 要求的文件描述符的数量.这个数字应该增加,否则,你将经常看到 too many connections 错误. 默认数值是100,我把它改为1024 . (2).record_buffer: 每个进行一个顺序扫描的线程为其扫描的每张表分配这个大小的一个缓冲区.如果你做很多顺序扫描,你可能想要增加该值.默认

  • 大幅优化MySQL查询性能的奇技淫巧

    回顾 MySQL / InnoDB 的改善历史.你能很容易发现.在MySQL 5.6稳定版本中从来没有在read-only 这么快的提速,它很容易搞懂,以及在read-only(RO)有着良好的扩张性.也很期待它在read+write(RW)上达到一个较高水平.(特别是在读取数据是数据库主要工作的时候) 然而.我们对于RO在 MySQL 5.6的表现也十分的高兴,在5.7这个版本中,主要工作集中在 read+write (RW)上, 因为在大数据的处理上还没能达到我们的期望.但是RW依赖RO下.

  • 脚本合并提升javascript性能示例

    每个<script>标签初始下载时都会阻塞页面渲染,所以减少页面包含的<script>标签数量有助于改善这一情况.这不仅仅针对外链脚本,内嵌脚本的数量同样也要限制.浏览器在解析HTML页面的过程中每遇到一个<script>标签,都会因执行脚本而导致一定的延时,因此最小化延迟时间将会明显改善页面的总体性能. 通常一个大型网站或网络应用需要依赖数个javascript文件.你可以把多个文件合并成一个,这样只需引用一个<script>标签,就可以减少性能消耗.文件

  • Jquery优化效率 提升性能解决方案

    例如有一段HTML代码: 1.总是从ID选择器开始继承 以下是引用片段:<div id="content">  <form method="post" action="#">  <h2>交通信号灯</h2>  <ul id="traffic_light">  <li><input type="radio" class="

  • SQL语句优化提高数据库性能

    性能不理想的系统中除了一部分是因为应用程序的负载确实超过了服务器的实际处理能力外,更多的是因为系统存在大量的SQL语句需要优化.为了获得稳定的执行性能,SQL语句越简单越好.对复杂的SQL语句,要设法对之进行简化. 常见的简化规则如下: 1)不要有超过5个以上的表连接(JOIN) 2)考虑使用临时表或表变量存放中间结果 3)少用子查询 4)视图嵌套不要过深,一般视图嵌套不要超过2个为宜 一.问题的提出 在应用系统开发初期,由于开发数据库数据比较少,对于查询SQL语句,复杂视图的的编写等体会不出S

  • 优化Apache服务器性能的方法小结

    测试与提高性能 Apache服务器已经被设计得尽可能的快,即使你用一台配置不高的机器,用不着进行太复杂的设置,它的响应内容就足以塞满以前的各种窄带连接.但随网站内容日益复杂和带宽的增加,对Apache进行优化以取得更好的性能变得日益重要起来. 如果优化的结果仅仅是极小的性能提升那真是浪费时间.试想一下,你花了好几个小时甚至几天调整Apache的各种参数但结果仅是几个百分点的性能提升?因此,在优化前你做的第一步应该是测试你目前的服务器的性能水平以便决定如何优化你的服务器并衡量优化的效果. 关于对A

随机推荐