[Work in progress] Flowtype typings

Hello there!


I’ve started to work on Flow types for Meteor. I know about these TypeScript ones, but there’s one thing… These are shallow. Let’s take this code:

import {Mongo} from 'meteor/mongo';

const Collection = new Mongo.Collection('collection');

const transform = doc => ({_id: doc._id, fields: Object.keys(doc).length});
const docs = Collection.find({}, {transform}).fetch();

What is the type of notes? Well, according to current TS types, it’s the collection type (inferred or whatever). My goal is to provide complete types. Current state allows you to do this:

(docs: {|_id: string, fields: number|}[]);

And of course throws an error here:

docs.map(doc => doc.other);

Yep, it’s correctly typed!


Main goal is to type whole Meteor core packages, namely this directory and (finally!) make a pull request to flow-typed.


Current version provides complete types for two medium-sized projects (you can see, which part of API are these two using, as the rest is not typed yet).

How can I try it?

Simply go here and clone it into your flow-typed directory.

How can I help?

  1. Drop it in your project.
  2. Fix something and/or type missing parts.
  3. Make a pull request.

It’s that simple!

Update 2018-01-10

Few people asked me, how do I work with Flow and Meteor. Here’s a .flowconfig working with both 1.5 and 1.6:


module.name_mapper='^\/\(.*\)$' -> '<PROJECT_ROOT>/\1'
module.name_mapper='^meteor\/\(.*\):\(.*\)$' -> '<PROJECT_ROOT>/.meteor/local/build/programs/server/packages/\1_\2'
module.name_mapper='^meteor\/\(.*\):\(.*\)$' -> '<PROJECT_ROOT>/.meteor/local/build/programs/web.browser/packages/\1_\2'
module.name_mapper='^meteor\/\(.*\)$' -> '<PROJECT_ROOT>/.meteor/local/build/programs/server/packages/\1'
module.name_mapper='^meteor\/\(.*\)$' -> '<PROJECT_ROOT>/.meteor/local/build/programs/web.browser/packages/\1'

We ignore .json files from Meteor sources (.npm is a directory for bundled npm modules), because some of them contains comments.


Love the initiative. I do not use flow type yet, but I do understand its advantages and I do believe that the price you pay (extra code) is worth it in the end.

Yes, it really is! And to be honest it’s not that big. The only price I see is the time needed for getting on with Flow (or static typing at all if you are not familiar with it).

Also, there’s no much more code as most types are inferred. That’s why it’s better (and, in a way, easier) to provide high quality typing for libraries.

1 Like

@radekmie what’s the status with this ? Do you plan on continuing it ? I think this will mark an important evolution to enterprise JS within Meteor.

@diaconutheodor Yes, I’m still continuing it. Right now I’m introducing Flow on another project, and it turned out to be BFS and not DFS implementation cycle… Long story short, it will be continued but I’m focusing on making it complete one by one rather than opening all and having none finished.

1 Like

Update: Three projects typed so far! Kind of milestone :rocket:

Nice! I believe you should share a bit of your knowledge in a Medium blogpost, like what are the challenges, what are the best patterns, what are some pitfalls. I have less experience in this regard, but definitely I see Flow as something that will be used in the future.

I am planning to create flow-typed for Grapher and RedisOplog, not sure yet how to nicely integrate them in a project… Maybe you can do it for uniforms first so I have some inspiration :smiley: :smiley:

I’ve been using VSCode with Flow Type integration it works just amazing. I love JS flexibility but I was missing the Java/C# consistency, now we have both, no doubt in my mind JS is gonna surpass any other language eventually.

Blog post? Well, it’s an idea. A good one actually.

About typings for Grapher and RedisOplog - I could help you with that. At the beginning, at least. About the uniforms - I’m on it for a long while (I’ve checked my git stash - for almost 6 months now), but I haven’t got time to finish it… New year’s resolution? Who knows!

I’m not very into statically vs dynamically typed languages (C, Lua and JS here), but it’s definitely easier to introduce someone into a typed project, even without a proper documentation.

1 Like

Hi @radekmie
Thanks for taking the initiative. I’ve added a PR to your repo covering another part of Meteor API.


Hi @radekmie, thanks a lot for this initiative! I just started using flowtype with meteor, and it’s great! I stumbled on a couple things:

  • My meteor modules aren’t mapped, flow can’t find them. I see that you mapped things to .meteor/local/build..., but I don’t have a build folder in .meteor/local, how does it work for you?
  • Question: what is the first module mapper doing? module.name_mapper='^\/\(.*\)$' -> '<PROJECT_ROOT>/\1'

Thanks a lot for what you do! :slight_smile:

Glad to hear that!

  • The .meteor/local/build is present after the app was run.
  • This mapper resolves absolute (root directory) imports.

Anyone uses this? I’m thinking of using flow and would love to hear some feedbacks.

I have been using Flowtype quite intensively for the past couple of years. Now in transition converting the whole codebase to Typescript (in the middle of it; not finished yet … but Typescript is overall MUCH better than Flowtype - in terms of maturity, tooling, community and development of the language driven more by developers’ requests than it is with Flow (where if you’re lacking something important, if Facebook doesn’t need it for the way they develop their software internally, you can wait for it for years and never get it, not even just accepted in Flow by them).
If you’re thinking of typing your code-base, I’d recommend doing it in Typescript right away, though the official support for Typescript in Meteor from MDG announced some months ago has not been released yet and you have to try various workarounds (I am not through it yet to give “the best working solution”)

I’m also close to migrating to TypeScript. Looking at some flow to TS conversion tools next…

I used flow-to-typescript from npm. It is not perfect but it can save a lot of tedious work as the first stage of code-base conversion before you do the rest of the “re-typing” in TypeScript manually if you used Flow’s capabilities to the max.

I tried typescript in a non-meteor side project last year, and while i loved the immediate help/autocomplete of arguments, in more complex scenarios (wrappers, HOCs, etc) it took to much time to write the correct typings. On top of that, meteor support for typescript is only a promise for a very long time.
I was thinking that flow would be a little bit easier to use.