Suggestion: Typescript plugins

[nojvek]

It seems in most typescript projects, the build setup will have tslint, tsc, and some form of minifier. This is also closely related to #8. The build setup also has someway of deciding whether to invoke the build pipe depending on what files have changed.

I believe typescript should have plugins just like babel. Basically the compiler has hook points at various before/after stages, plugins can modify scanner behaviour, parser behaviour, emitter behaviour.

This means tslint can hook in and do its checks at parser/scanner stage. There could be a plugin to support a much stronger inference, kind of like flow at the checker stage. The minifier can hook in the emitter stage.

I could write a plugin to support extra syntatic sugar. e.g is isn't, and, or, not. a plugin to support Coffeescript like omission of parenthesis and curly braces.

There could be a plugin to inline function calls, or a plugin to output computationaly intensive code as asm, or wasm.

There could be a plugin to cache the AST's so when the same file is encountered with the same hash, it can load the AST from cache speeding up the compiler.

This would mean typescript does what it needs to do the best, the community can build plugins rather than having to fork the whole typescript project to support a simple feature.

tsconfig.json would have a plugins array and just like npm init, tsc can auto download the plugins if it doesn't have them.

What do you think?

[mhegazy]

There are different levels of extension, each with different implications on the system, and each enable a new set of scenarios.

We are looking into refactoring our emitter to a transformation pipeline (#5595); that will enable multiple scenarios related to emitter/code generation/code optimization extensiblity. We also have a request for a type-provider-like extension point (#3136), allowing for extensions to create new types from other sources than the user code, e.g. JSON or database. We are also looking into Language Service extensibility (#6508), allowing for additional liniting/design time experience customization.

Extensibility points for augmenting the language syntax, is something that would fall low on the list; TypeScript has a type system aspect that other transpilers do not have, and changes to the syntax require changes to the typesystem as well, and i do not think this is an easy task. For these, i would recommend forking the compiler to experiment with it, and we can always pull that in based on the results of the experiment. this was the model we followed for the JSX support.

In short, externsibility is one topic on our roadmap; I would expect different extensibility points to show up incrementally in future releases.

I believe this issue is already captured in multiple existing issues, listed above, so i will close it as a duplicate. feel free to add comments/proposals to these issues, or file other issues for specific extensbility points needed.