This project is read-only.


Make the TypeScript Compiler extensible


It would be interesting to extend TypeScript in a more reliable fashion by allowing the compiler to be extensible. As a result, 3rd parties could leverage the published TypeScript version and, through the use of a composition or plugin model, extend TypeScript along a well-defined API surface.

Ideally it would be a great benefit to have a mechanism where a plugin or extension author could subclass the Compiler, Scanner, Parser, Pull-Type Checker, Emitter, and other interesting internals, to add additional capabilities.

As a result, plugin authors could use the well-defined surface to add additional behavior to TypeScript, such as minification at compile time, extensions to the language, embed other languages, localize at compile time, emit debug or coverage metadata, refactoring, etc., without needing to fork the entire codebase and find a means to keep the fork and the extensions in sync.

Please consider providing a published extensibility API for the TypeScript compiler, and a means to provide plugins either via command-line switches and/or by providing a global "plugins" folder in the TypeScript installation path.

There of course are open questions and likely concerns around forcing TypeScript into a well-defined API surface, which could make it more difficult to change the API to add future capabilities, as well as how plugins could effectively interface with tooling such as the Visual Studio language extensions.
Closed Jul 28, 2014 at 11:18 PM by jonturner
As part of our move to GitHub, we're closing our CodePlex suggestions and asking that people move them to the GitHub issue tracker for further discussion. Some feature requests may already be active on GitHub, so please make sure to look for an existing issue before filing a new one.

You can find our GitHub issue tracker here:


danquirk wrote Jul 19, 2013 at 7:14 PM

Thanks for the suggestion, assigned to Jonathan.

thorn0 wrote Oct 6, 2013 at 9:24 PM

As an example use of compiler extensibility, we can think of AngularJS and its DI annotations.
export class TodoCtrl {

    // $inject annotation.
    // It provides $injector with information about dependencies to be injected
    // into constructor. It is better to have it close to the constructor, because
    // the parameters must match in count and type.
    // See
    public static $inject = [ '$scope', '$location', 'todoStorage', 'filterFilter' ];

    // dependencies are injected via AngularJS $injector
        private $scope: ITodoScope,
        private $location: ng.ILocationService,
        private todoStorage: ITodoStorage,
        private filterFilter
    ) {
In order for DI not to break after minification, developers have to add $inject annotations manually. Would be cool if it was generated by the compiler.
export class TodoCtrl {

    [Injectable] // this attribute tells the compiler extension to generate $inject for us
        private $scope: ITodoScope,
        private $location: ng.ILocationService,
        private todoStorage: ITodoStorage,
        private filterFilter
    ) {

robfe wrote Oct 7, 2013 at 1:57 AM

I'd love to see this. Postsharp-style attributes ( would be amazing (except they'd probably transform a compile-time syntax tree rather than doing runtime AOP).

Another use case for this could be an attribute that makes all of a class' properties into knockout observables, or a way to control which method is used to implement inheritance (so I can use a JS framework's object.extend method instead of typescripts, for specific classes instead of the current global hack)

thorn0 wrote Oct 9, 2013 at 2:08 PM

On the other hand, this might be achievable with macros if they were added to the language.

Wolverine_ wrote Jan 31, 2014 at 5:38 PM

This is probably my #1 request for the language. I think a feature like this would really help strengthen the TypeScript platform / ecosystem. I can think of quite a few uses, most notably:

1 - Tree-shaking assertions, and other debug-related development code before shipping.
2 - Custom linters that enforcing company-specific guidelines on various code structures.

Please consider!

markbuer wrote Mar 17, 2014 at 1:39 AM

I wrote a small story about module resolution plugins here.

jamesnw wrote Apr 9, 2014 at 2:20 AM

This would be great for custom APIs. I think this would open many creative doors. :)

lohankin wrote Apr 9, 2014 at 3:29 AM

Indeed, this is #1 feature IMO. Mother of all features. Please give users the opportunity to explore their ideas.

Arnavion wrote May 24, 2014 at 12:51 AM

Another use: adding JSDoc comments to the AST based on type information. Currently I have to hack with TS internals to achieve that: