Search Terms

Serialization, deserialization, dumping, dump source file, compiler cache

Related issues

#25658, TypeStrong/ts-loader#825

Suggestion

I'd like to suggest to add an API to be able to (de-)serialize any parsed Node or make parsed AST be easy (de-)serializable by, for example, JSON.stringify().

Use Cases

It can be used to make cache of parsed source files, which can be used between compilations without parsing unchanged source files again.

For example, for our project at the moment we have the following times for compilation:

$ ./node_modules/.bin/tsc --diagnostics --skipLibCheck
Files:          1767
Lines:        226078
Nodes:       1036945
Identifiers:  315470
Symbols:      380158
Types:        137886
Memory used: 497393K
I/O read:      0.63s
I/O write:     2.09s
Parse time:   10.79s
Bind time:     2.10s
Check time:   12.47s
Emit time:    10.72s
Total time:   36.09s

$ ./node_modules/.bin/tsc --diagnostics --skipLibCheck --noEmit
Files:          1767
Lines:        226078
Nodes:       1036945
Identifiers:  315470
Symbols:      380158
Types:        137886
Memory used: 500125K
I/O read:      0.83s
I/O write:     0.00s
Parse time:   15.20s
Bind time:     3.13s
Check time:   17.59s
Emit time:     0.00s
Total time:   35.92s

(I have no idea why --noEmit does not reduce "Total time" by "Emit time" - it is strange)

I hope, if we'll have such API or even cache by tsc, it can reduce compilation time, especially Parse time.

Also, in this case, the TypeScript package can be published with already parsed lib files, what can reduce compilation time even without enabling --skipLibCheck option.

Examples

For example, we can override getSourceFile method in CompilerHost and provide files from cache if file is not changed since last compilation. It can be done via provided methods like ts.serializeNode(node: ts.Node): string | ByteArray / ts.deserializeNode(nodeData: string | ByteArray): ts.Node.

Also it can be added to tsc command as arg --use-cache (or something like that) to do it by default (but I believe in this case we also need to have new option like cacheDir or --force).

The similar cache can be found in bazel rules_typescript, but it is in-memory cache.
In our internal tool we have very similar in-memory cache too (it allows speedup multiple compilations the same files).

Checklist

My suggestion meets these guidelines:

• This wouldn't be a breaking change in existing TypeScript / JavaScript code
• This wouldn't change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn't a runtime feature (e.g. new expression-level syntax)