Safe & Efficient Gradual Typing for TypeScript

Abstract

Current proposals for adding gradual typing to JavaScript, such as Closure, TypeScript and Dart, forgo soundness to deal with issues of scale, code reuse, and popular programming patterns. We show how to address these issues in practice while retaining soundness. We design and implement a new gradual type system, prototyped for expediency as a 'Safe' compilation mode for TypeScript. Our compiler achieves soundness by enforcing stricter static checks and embedding residual runtime checks in compiled code. It emits plain JavaScript that runs on stock virtual machines. Our main theorem is a simulation that ensures that the checks introduced by Safe TypeScript (1) catch any dynamic type error, and (2) do not alter the semantics of type-safe TypeScript code. Safe TypeScript is carefully designed to minimize the performance overhead of runtime checks. At its core, we rely on two new ideas: differential subtyping, a new form of coercive subtyping that computes the minimum amount of runtime type information that must be added to each object; and an erasure modality, which we use to safely and selectively erase type information. This allows us to scale our design to full-fledged TypeScript, including arrays, maps, classes, inheritance, overloading, and generic types. We validate the usability and performance of Safe TypeScript empirically by type-checking and compiling around 120,000 lines of existing TypeScript source code. Although runtime checks can be expensive, the end-to-end overhead is small for code bases that already have type annotations. For instance, we bootstrap the Safe TypeScript compiler (90,000 lines including the base TypeScript compiler): we measure a 15% runtime overhead for type safety, and also uncover programming errors as type safety violations. We conclude that, at least during development and testing, subjecting JavaScript/TypeScript programs to safe gradual typing adds significant value to source type annotations at a modest cost.

Refinement types for TypeScript

“…Figure 12 presents the dynamic behavior of the two languages. Rules for FRSC have been adapted from Rastogi et al [27]. Note how in rule R-CAST the cast operation reduces to a call to the built-in check function, where T encodes type T .…”

“…We selected benchmarks that make heavy use of language constructs connected to the safety properties described above. These include parts of the Octane test suite, developed by Google as a JavaScript performance benchmark [12] and already ported to TS by Rastogi et al [27], the TS compiler [22], and the D3 [4] and Transducers libraries [7]:…”

“…Compared to X10, in RSC: (a) we make mutability parametric [41], and extend the refinement system accordingly, (b) we crucially obtain flow-sensitivity via SSA transformation, and path-sensitivity by incorporating branch conditions, (c) we account for reflection by encoding tags in refinements and two-phase typing [38], and (d) our design ensures that we can use liquid type inference [28] to automatically synthesize refinements. [40] and their JS implementations [8], and Rastogi et al extend TS with an efficient gradual type system that mitigates the unsoundness of TS's type system [27].…”

Automatic non-functional testing of code generators families

“…TypeScript. TypeScript 4 is a typed superset of JavaScript that compiles to plain JavaScript [19]. In fact, it does not compile to only one version of JavaScript.…”

Hybrid Typing of Secure Information Flow in a JavaScript-Like Language

“…Since then, the TypeScript programming language [11] was proposed as a flexible language that adds optional types to JavaScript with the goal of harnessing the flexibility of real JavaScript, while at the same time providing some of the advantages otherwise reserved for statically typed languages, such as informative compiling errors. Recently, Rastogi et al [12] designed and implemented a new gradual type system for safely compiling TypeScript to JavaScript. The soundness of the proposed approach is guaranteed by combining strict static checks with residual runtime checks.…”