TypeScript 开发团队刚刚发布了 TypeScript
2019
上半年的发展路线图。2019年1月至6月,开发团队将重点关注以下目标:

图片 1

大半夜的JavaScript Weekly发来贺电:TypeScript 2.0 Final Released!

  • 覆盖更多 JS 开发者

  • 提高生产力

  • 改善用户体验

  • 提高社区参与度

  • 完善基础设施

TypeScript 团队继续以双月发布节奏发布了 TypeScript
3.3,这一版本改进了调用联合类型的行为以及复合项目增量文件的监听性能。该团队还宣布了未来六个月的TypeScript
路线图。

没错,继Angular2发布之后,TypeScript今天也发布了2.0版本,这不禁让我浮想一番。如果要说TS和JS最明显的差别,我想一定是Type
System,所以今天我们就聊聊类型系统在前端发展历程中,到底扮演了怎样的角色。

不过,开发团队也强调,该路线图更像是一套指导方针,而不是一定要完成的任务,后续可能会根据不断变化的需求和用户反馈进行调整。

TypeScript 3.0
增加了对复合项目的支持,可以将大型项目分成较小的项目,改进–build
模式下的构建时间,而且只重新编译必要的项目和依赖项,以此来优化项目间的构建。同时还增加了一个项目内增量构建
API,用于更新发生变更或包含可能会影响类型检查的依赖项的文件。

如果要你把PV上百万级别的Web
Application用一门在10天内撸出来的编程语言来开发,我想你肯定不会放心的。然而事实上我们现在都是这样干的,JS已经成为了最流行的编程语言。JS现在所承担的使命已经完全超出了当年设计的初衷,虽然TC39一直在填坑,并且发展到如今的ES6已经相当成熟了,但仍然留下了一些历史包袱,并不能改变这是一门动态弱类型脚本语言的实质。

部分细节如下:

在 3.0 发布之后,有关在复合项目中使用–watch
标志的性能问题的抱怨有所增加。复合项目并没有利用项目内增量构建功能,而是进行完整的项目构建。

因此在前端工程化不断壮大的过程中,为了避免采坑,人类同JS最佳编码实践方式展开了旷日持久的战争。

TypeScript 和核心类型系统

现在,在 TypeScript 3.3 的–build 模式下使用–watch
标志可以利用增量文件监听功能显著改善构建时间,可以将构建时间平均缩短
50-75%。

最开始,大家都只是取其精华,去其糟粕,如《JavaScript语言精粹》一书所说:你们只需要用我说的就好了,其他的垃圾都不要学,并且千万不要在项目里面用。

  • 以类型安全(type-safe)的方式提供流行的 JS 模式

  • 提高语言表现力

  • 验证类型关系(Proving relationships between types)

  • 更严格的设置

  • 实现 ECMAScript 功能

TypeScript
支持联合类型,开发人员可以访问联合成员所共有的属性。在调用类型时,如果每个类型没有具有相同参数的调用签名,就很难为返回类型定义联合。

一般情况下每个公司都会出一套最佳实践的编码规范,程序员需要统一代码风格,按约定编写代码。但规范的约束力很低,结果在项目赶着上线的情况下还是写出了翔一样的代码,所以更好的方式是用工具来规范代码,发现一些潜在问题,通过工具来强制约定编码。比如JSLint,JSHint,以及ESLint,都是设定了一系列编码约定,让你避免写出一些糟糕的代码。

生产力

在 TypeScript 3.3
中,每个联合成员的参数组合在一起形成新的签名。只有当联合中有一个类型具有多个重载并且有一个类型具有通用签名时,才会应用新的行为。TypeScript
团队在 TypeScript 3.3
中添加这一新增功能,作为改进方案的第一步,并可能在将来的版本中做出进一步的改进。

另外一种思路,就是抛弃使用JS作为开发语言,或者只是把他当成“JVM”,然后采用另外一种设计更加严谨,不容易采坑的语言来编程,比如CoffeeScript和TypeScript,开发完后再转译成JS来运行。

“主动” 快速修复 (类似于“建议”功能)

与最近发布的版本相比,TypeScript 3.3
只提供了相对适度的新功能,主要是因为双月发布节奏刚好碰上了寒假,但也可能是因为
TypeScript
团队在六个月路线图中提及的内容,线路图重申了除了为语言添加更多功能之外的工作:

如果觉得这种方式过于激进,那么可以采用渐进的方式,比如Flow。Flow可以在开发时对代码进行静态类型分析,用写强类型的方式来写弱类型的JS。实质上这有很多好处:

声明文件修复和重构

  • 将类型带给所有开发者;
  • 借助强大的工具提高生产力;
  • 可访问性和用户体验;
  • 社区参与;
  • 基础设施和工程系统;
  1. 强制声明类型,IDE和编辑器可以通过静态类型分析发现代码隐藏缺陷,同时也能够提供更强大的自动补全,智能代码提示和纠错,达到Java/C++级别的开发体验。
  2. 可避免类型隐式转换带来的消耗,提高运行效率。实际上JS引擎在运行时很大的开销都花在类型分析上。
  3. 可读性/可维护性增强。一眼就能看出这个变量是String还是Number,代码维护也更清晰,并且通过注释工具生成的代码注释也会更加详细,后面换人维护时也更容易上手。
  • 生成缺失的 .d.ts 文件

  • 本地 fork @types 包

TypeScript 团队仍然专注于添加新的 ECMAScript 功能和改进
TypeScript,但它已达到了一定程度的稳定性。

这些优势,其实都是类型系统所带来的强类型语言所具有的开发优势,无论是在开发体验还是后期项目维护上,都要优于目前的JavaScript。

“Bread and butter” fixes &
refactorings(指适用于大多数用户的代码修改和修复)

在过去的一年中,TypeScript 在 JavaScript 生态系统得到了大规模采用,包括
Vue.js 的下一个版本、Jest和Storybook将迁移到
TypeScript。很多开发人员和项目正在从 JavaScript 迁移到
TypeScript,而有一些则从 Flow 迁移到 TypeScript。

接下来,我们就以渐进的方式,来感受一下类型系统带给我们的好处。

迁移工具

来自 Hootsuite 的软件工程经理 Ovidiu Bute 解释了他们为什么要迁移到
TypeScript:

Flow.js

很多情况下我们都是在维护项目,不可能为了增加类型检查来修改老的项目代码。Flow可以在不修改代码的情况下,通过注释的方式来进行静态类型分析,这为我们提供了一个很好的过渡方式。你可以随时在任一个项目里面集成Flow。

/** @flow * 只需要在文件头部添加flow注释,Flow就会认为这个文件需要静态分析并检查*/function foo { return x * 10;}// 这样调用Flow就会给出错误提示:string和number类型不兼容foo('Hello, world!'); 

这种无侵入式的集成,可以检测出一些比较低级的错误,如果要支持更多强大的分析,就需要写侵入代码了,比如手动类型注释:

/* * @flow * var : [type] 指定变量类型*/function add(num1: number, num2: number): number { return num1 + num2;}// 这样调用就会报错,因为参数2已经被声明为number了var x: number = add;

这样的代码是不能直接运行的,还是需要Flow工具转译成原生JS才能执行。这种方式就更适合新的项目,一旦新项目直接集成了Flow套餐,就可以直接使用Flow支持的更多功能,并且配合IDE给出更好的开发体验。

以Mac下的VSC为例,首先安装本地Flow环境:

brew updatebrew install flow

然后在VSC中安装启用vscode-flow插件, ⌘+’
打开用户配置,禁用VSC自带的JavaScript校验功能(设置javascript.validate.enable为
false),并设置好flow的安装目录:

图片 2图片描述

剩下的套路就跟Babel,ESLint一样了,在项目根目录下面建立一个.flowconfig文件,配置一些校验规则:

图片 3图片描述

vscode-flow插件检测到.flowconfig配置后就会启动flow服务去实时分析项目代码,当你开发的时候就能感受到比原生编辑器更加强大的自动补全和智能提示了。比如当你require一个util模块时,flow能分析出util模块内结构,并且当你调用util方法不当时给出提示:

图片 4图片描述

以上只是介绍简单流程,并且还是无侵入式的校验,如果再加上手动类型声明的话,还能提供更多功能。

速度、可扩展性和稳定性

我们还观察了与这两个项目相关的社区。Flow 由 Facebook
以一种非常封闭的方式驱动,开发从来都不透明,也没有提供公开的路线图,除
Facebook 以外很少有人参与这个项目。相比之下,TypeScript 在几年前迁移到
GitHub
之后就开始拥抱开源。他们保持最新的路线图,接受外部贡献,并与社区保持非常密切的关系。

TypeScript

TS的做法更彻底,如果有一个全新的项目可以自由选择技术方案的话,我一定会选TypeScript而不是Flow.js。可惜的是,在公司里面大部分时候都依赖公司自身的技术体系,在做技术选型的时候都要依赖团队的技术栈。就比如大家都用ES6,你选择TypeScript,那么之后别人来维护你的代码成本就非常高,除非你能煽动整个团队,整个集团使用:)一般情况下这是不可能的,我想这也是TS难以普及的重要原因。

但是,这并不妨碍TypeScript成为一门优雅的前端开发语言。ES6有的它都有,ES6没有他也有(泛型/枚举/类型推导等只有强类型语言才有的一些特性),而这些特性恰恰更加适合日益壮大的工程化的前端,适合编写出可维护性代码。再配合微软自家的VSC,开发体验妥妥的:

图片 5图片描述

至于TypeScript
2.0带来了哪些新特性,请直接戳GitHub:

前几日GitHub
发布了2016开源报告,JavaScript众望所归的荣登榜首,让众前端激动不已:

图片 6图片描述

然而让我意外的不是排在第一的JavaScript,而是最后的TypeScript:

图片 7图片描述图片 8图片描述

看这增长趋势,微软是要协TypeScript在开源之路上越走越远了。

私认为,无论最后是不是TypeScript,类型系统都带来了更好的开发体验,代码质量,代码可读性和可维护性,这正是一个大型或长期项目所必须的,也是现在和未来的前端工程所需要的。所以实在是没有不学的理由,如果你觉得TypeScript像极了C#更适合后端程序员,那么学习它或许是你迈向全栈的一小步哈哈。

在 TSServer 中自动卸载项目

Babel 原始作者和 Facebook 工程师 Sebastian McKenzie 在回答用户提出的有关
Flow 的功能时解释道:

打磨 & 修复 Composite 项目

老实说,我建议现在切换到 TypeScript,因为 Flow 的开源之旅不被重视。

解决性能问题

Flow 团队已经开始着手解决这些问题,可以在这里看到最近的进展和 2019
年的计划。Facebook 软件工程师 Avik Chaudhuri 阐述了从 Flow 到 TypeScript
的迁移:

  • 支持 ETW

  • 基础架构基准测试

  • 追踪并修复回归

最近,一些最初由 Facebook 创建的开源项目计划使用 TypeScript 重写。在
Facebook,我们非常重视各个团队在创建路线图以及在他们尽最大努力构建产品时的独立性。一些项目决定切换到
TypeScript,有了外部贡献者,开发可能会更容易,我们尊重他们的决定。

针对 TSServer 的自动化测试基础架构

一些现有框架(如 Angular、Dojo 和Ionic)已经使用了
TypeScript,一些框架则计划切换到 TypeScript,或者至少提供了类型定义或
CLI 工具,由此可见,一大部分 JavaScript 开发人员现在正在采用
TypeScript。

图片 9

TypeScript 是基于 Apache 2
许可发行的开源软件。开发人员可以通过TypeScript GitHub
项目参与贡献和提供反馈,并遵守TypeScript 贡献指南和微软开源行为准则。

更多细节可查阅:TypeScript Roadmap: January – June
2019

(本文章转载自infoq, 如有侵权, 请联系作者删除)

(文/开源中国)