Integrate type checking into Meteor

[mitar]

There are tools like Flow which provide some help in type checking JavaScript. How would one integrate this into the Meteor workflow? As a tinytest? Travis CI? Or something which runs every time during bundling?

[mquandalle]

I agree that static type checking would be a great addition. The flow compiler could probably be integrated as a community package handling .flow.js files (not perfect, but still a not too bad solution).

I also want to underline the fact that even with static type checking, we'll still need runtime type checking for all users inputs, particularly on the server side (currently handled by the check/Match API). Maybe the static and runtime type checking semantic could converge in some way? Does ES6 say something about that?

[awatson1978]

+1
Would love to see a Flow package, or something similar. I've even wondered about compiling Meteor to a Dart VM.

[priezz]

I believe it is possible to use Flow as an external tool together with Babel module, which is already available for Meteor. It is just required to use .jsx extension as it is the only one supported by babel module and flow.

As for the runtime checking we could use this library https://github.com/gcanti/flowcheck.

[mitar]

Hm, but it seems it is not possible to use Flow with CoffeeScript. :-(

[priezz]

@awatson1978, I have tried that (not for Meteor, but anyway...) by integrating Dart into HarpJS static generator as one of the preprocessors - Dart compiler works extremely slow, so after a day of use I realised it was not very bright idea to use it in realtime.

@mitar, that is possible with CoffeScript as well, but the way is a bit sophisticated. Flotate (https://github.com/jareware/flotate) should help. The code will be a bit ugly with all those comments but should work. As an option we could think about CoffeScript syntax extension, but I am still not sure what is better, to keep code nice looking or to keep compatibility.

[mitar]

Has anyone made .flow.js package for Meteor?

[priezz]

Is seems that Flow currently supports annotations in comments the same way flotate does. However, I see same problems here.

[merunga]

I made my code start working with the flow command using grigio:babel with the /* @flow */ and types annotations, without meteor complaining about them. But 2 issues made me quit it:

• first, you have to define all Meteor APIs as described here, which is a pain.
• the other problem is related the way meteor export variables: flow won't find local package variables (defined without var) or exported explicitly by your package (api.export)

I guess the API interfaces problem can somehow be easily resolved, but I think the second one is kind of tricky.

Here's the output of the flowcommand:

demo-app/packages/leaderboard/client/views/leaderboard/controller.es6.js:3:21,31: identifier ReactiveVar <= core package exported class
Could not resolve name

demo-app/packages/leaderboard/client/views/leaderboard/controller.es6.js:8:5,10: identifier Meteor <= core class
Could not resolve name

demo-app/packages/leaderboard/client/views/leaderboard/controller.es6.js:11:26,32: identifier Players   <= local package exported variable (api.export)
Could not resolve name

demo-app/packages/leaderboard/client/views/leaderboard/controller.es6.js:26:1,21: assignment of identifier LeaderboardController  <= package local variable
Could not resolve name

[jamiter]

It's already in the ecmascript package: https://github.com/meteor/meteor/blob/devel/packages/ecmascript/README.md#syntax

Search for "flow".

[trusktr]

Another possibility could be to fork the module and ecmascript packages (not sure if exactly those packages, but for example) then add the flow checking step. Then, all that would be needed (supposing we forked and modified the correct packages):

meteor remove modules
meteor remove ecmascript
meteor add someone:modules-flow
meteor add someone:ecmascript-flow

(not sure which packages actually need to be forked, but just mentioning that the concept is probably not too hard to do)