Add a type checker to Popcode's JS validations

Wouldn't it be cool if we could give students feedback based on type checking?
The likely constraints to any type checker we use:

1. Runnable in browser
2. Can parse regular JS
3. Has typings for a healthy subset of Popcode's supported libs (jQuery, lodash, Bootstrap, Mustache)

The current most popular type-checked ~supersets of javascript are TypeScript and Flow.

Here's my opinion on how each breaks down against those 3 constraints (disclosure: I am much more familiar with Flow):

TypeScript:

1. This blog post details how you can get TypeScript type checking in the browser. Adapting to Webpack is left as an exercise for the reader.
2. I don't know enough to say. I know that TypeScript will be fine with trivial examples of untyped JS, but I don't know how well it does with more complicated code samples.
3. TypeScript has typings for all four supported libs.

Flow:

1. Flow has a (mostly undocumented) compiled-to-js version, which is used in the "Try Flow" sandbox. Instructions for building this file are at the bottom of these instructions.
2. Flow is designed for the gradual introduction of types, and being run on code with no typings is a first class use case. That said, there are still a number of ways that the checker can get "confused", which is to say that Flow has opinions which will clash with a lot of beginner-level code patterns, in particular with regards to object mutability. Example.
3. Flow has available typings for jQuery and lodash.

With both options, a major component of this feature will be filtering messages to ensure that anything students see will be

• Fixable (e.g. not requiring type annotations or special syntax)
• Pedagogically sound (we're not trying to teach them more advanced concepts like variance here)
• Accessible (e.g. the Flow message in the example could be simplified to "Your object doesn't have the field 'newField'").
• Unique (we already have JSHint and Esprima to complain about syntax issues and undeclared variables)

Other considerations:

• bundle size
• speed of checks

No files or tests are named. Start by reviewing the existing JSHint and Esprima validations, then compare browser-compatible TypeScript and Flow against the stated constraints and message-filtering needs. Done means selecting an approach that checks supported JavaScript and libraries while showing only fixable, pedagogically sound, accessible, and non-duplicate feedback.