Compile / edit time pluggable analyzers like C#

[Ciantic]

It would be nice to have similar plugabble compile time / editing time analyzer plugins as introduced in C# in Build 2015, see the video.

Analyzer is a library that can do additional syntax checks, tag lines as errors / warnings, and are interpreted by language service.

I can imagine one could do similar things with it as Facebook's flow does e.g. own nullable checking just by writing own analyzer. This would be configurable from tsconfig, maybe one could whitelist the files each analyzer works on. This way the nullability check analyzer would only complain about the code I want.

[DickvdBrink]

I would definitely use this if it became available!
For know I always create a simple nodejs application which uses the TypeScript compiler to analyse the things I care about, but this would be a nice improvement!

[jbondc]

Thanks for sharing, seems like all the building blocks are almost in place. async may be a blocker though for TypeScript.
You'd need a cancellation token or something similar for this to work with threads.

+1 to Visual Studio debugging Visual Studio #2656 😮
This mixing of syntax model + semantic model is very nifty stuff.

[Deathspike]

This would be great. It would also open good integration for things like design-by-contract and of course nullable checking. I would love this feature.

[CyrusNajmabadi]

As someone who was heavily involved in this work in https://github.com/dotnet/roslyn, i'm definitely very interested in enhancing TypeScript in this space.

Unfortunately, there are a lot of hard issues here that make this a non-trivial for us. For one thing, our compiler has been designed for raw speed on a JS engine, rather than extensibility. To be very fast on JS engines, you need to avoid lots of abstractions and complex layering in your objects. So, for example, our AST nodes work very differently than Roslyn's do. This includes:

1. Our ASTs are not full fidelity. You don't get all information from the source code in the AST, and it's not possible to fully recreate the source code from the AST. This is problematic for analyzers that want to have fine-grained understanding of your code syntax, as well as fine-grained ability to manipulate it.
2. Our ASTs do not follow a consistent model. You can get things like delimited lists without delimiters in our model. In Roslyn, this can't happen.
3. Our ASTs are not persistent. This is problematic for things like building analyzers/fixers. You want immutability so that you can create speculative forks of your code that you can then format/simplify/continue-to-analyze/etc.
4. Our ASTs are not immutable and do not prevent you from performing operations on them that will break our compiler. Indeed, in our compiler almost everything in our data model is a public mutable field. This is great for perf, and really bad for a safe API. In Roslyn, everything is immutable. When you change a tree, you're not affecting any existing tree, or any compilation that depends on that tree. Everything in the system remains consistent and sane. in our model if you go an edit our trees, then many things will break. All our assumptions about how the tree relates to the source code will no longer be true. Data we've stored in the tree may or may not be valid post your edit, and we'll have no idea. Our incremental parser will likely be missing very important information it needs to work with this tree. Someone may change some piece of data out from underneath them (esp. if we did this in an async manner). etc. etc.

Furthermore, the JavaScript language and engines are missing many useful features that Roslyn heavily leans on for performance. For example, Roslyn takes huge advantage of structs in order to provide their dual Red Green Trees. By using structs they can effectively have two different tree representations, with only marginal memory/heap/gc overhead.

All of these deviations we made from Roslyn (which we understood and acknowledged when we did this work), were for performance reasons. They allowed us to provide a fast and lean compiler initially. Though they do now impact our ability to better supply things like analyzers/fixers in as simple a manner as Roslyn provides them. My hope is that as time moves on we can get these same sorts of features, while still maintaining our goal of a fast and lean compiler.

[nbellowe]

I just wanted to post something I posted in the closed post here, just to give a reference of a couple possible uses. Begin quote ->

Here are a few examples of possible extensions:

Add language support for defining properties with getters and setters.

Too big of a change, possibly not useful enough to warrant a change in Typescript, but it would be super cool if I could make a seperate npm package called typescript-properties, and anyone could pull that, and utilize it in there apps. This could maybe be an example that decorators could take care of, not sure.
property hello:T
compiles to
_hello:T
get hello():T { return this._hello }
set hello(v:T){ this._hello = v }
Add preprocessing to the code that doesn't break source mapping.

    #IF(DEBUG)
       expr;
    #ENDIF

While this can be accomplished with external tools, it breaks source mapping. With a complex build, like:

Original TS
Post-pre-processed TS
Compiled TS (Javascript) and sourcemaps to PPP-TS
Single-file JS (may need to be ordered in optimal way) & source map to PPP-TS if the tool supports input source mapping.
Minified Javascript & source map & source map to PPP-TS if the tool supports it.
-- note(UglifyJS can optimize out constants, so defining a const DEBUG=true|false can optimize out debug code as well. if(DEBUG) expr;)

[alexeagle]

👍
Check out http://error-prone.info where we did this for the Java compiler. I think we can find lots of statically analyzable bugs, and doing so in the compiler is much better than a standalone tool because you are guaranteed that everyone on the team complies with the rules.