Feature request: support TypeScript 'out of the box'


I’ve been struggling a lot lately with TypeScript. I did get it to work with Meteor but it was a lot of work. I don’t think though that I will end up using it in production because it’s too hacky.

In your next version what do you think about supporting TypeScript out of the box? It would be a great addition to the Meteor offering. I think many serious people and projects are embracing TypeScript. It would be super nice to have Meteor suggest that people adopt typed JS because it’s the future and it’s the intelligent way to write code.

I’ve also been following Apollo keenly and as I see it you’ve also gone the TS way with Apollo. https://github.com/apollostack/apollo-client/issues/6. Of-course it’s for internal dev.



Type-checkers like TypeScript and Flow are too subjective IMO. Some people want to use them, some people want to just use pure JavaScript. I wouldn’t want it forced on me. An option, though, maybe.

Relevant: https://www.google.com/webhp?sourceid=chrome-instant&ion=1&espv=2&ie=UTF-8#q=typescript%20vs%20flow

I agree, TS should be a first class citizen in Meteor, its simply a much better dev experience even if you never really use the language as the type definitions are far superior. IMO its much more than Flow and isn’t just about types.

There’s no reason it will be forced, its like React vs Blaze or ES2015 support, choose what works for you.


I started going down the path of Flow recently. I’m curious what you see as advantages of TS over Flow.


Yeah, I’ve explored Flow too. Somehow, I like TS better.

(PS: Also see https://github.com/apollostack/apollo-client/issues/6, where Apollo developers discuss TS vs Flow too)

I agree that type-chekers like TypeScript are be subjective. Some use them, most use JS. The idea is to suggest usage of TS.

Just like Meteor suggests writing code in a particular way https://guide.meteor.com/code-style.html.
Or, how Meteor supports eslint. again - https://guide.meteor.com/code-style.html#eslint

Like so, Meteor would offer everything TS configured and ready to go ‘out-of-the-box’ and suggest forward-looking best practices of typing. All .ts (or .tsx) files would automatically be converted to .js (or .jsx) files. Warnings would be displayed in console and/or command.

That’s all. People are still absolutely free to use ‘normal’ JS.

One thing I found with TS was that ‘it just works’. Flow is somewhat less easier to get started with.
But, TS is still working on a few things that Flow has but TS does not have. See https://github.com/Microsoft/TypeScript/pull/7140. I think they have implemented it though now. IMO TS will be a standard very soon.


This was the biggest thing for me. Also it saved me all of the trouble of also setting up babel, editor support, etc - just one tool to do all the stuff I need instead of many.

1 Like

Interesting. I set up a project with Flow, and honestly I didn’t find it too complicated. Just a few npm packages to install, some edits to .bablerc and .flowconfig. I’ll have to check out TypeScript as I haven’t given it a fair assessment yet.


1 Like

Did you manage to get completion in your editor working?

I’m not sure I like that TypeScript is its own file extension and transpiles into JS, whereas Flow is just embedded in the JS files. Flow seems to function more like ESLint, analyzing and making suggestions, whereas TypeScript is a transpiler.

1 Like

Yep! Works great. (in WebStorm)

Yeah for me it really came down to two main things in favor of TypeScript:

  1. Super duper easy to set up visual studio code with editor completion etc - I really couldn’t get Nuclide/Atom to work with Flow and I don’t have Webstorm
  2. Availability of community type definitions - TypeScript has type definitions for basically every library ever, and my perception was that those are not as complete for Flow

Typescript with Atom is easy.

Since typescript transpiles into regular js I don’t see why there would be a need for MDG to support it. There’s nothing to support if you setup your edit tool of choice properly. TS should be invisible to Meteor.

These are good points. And if someone is starting a new project, TypeScript is perhaps the best option.

If you already have a large app, Flow might be easier, because you can add a @flow annotation at the top of only the files you want to check with Flow. In theory, TypeScript is also possible per file, but it’s hard to work with it if you don’t go all in. I talked with @martijnwalraven about this, and he confirmed that this is the case with developing Apollo. All in is nice. If some files aren’t TypeScript it gets harder. Are there more people experiencing this?

I got Flow working with Meteor and wrote a blog post about it. I plan to add an example repo soon. Here is the post:


Awesome post, thanks for that!

1 Like

Were you able to comebine Flow and ESlint? It looks like you have to select either Flow or JS in webstorm, making it only check Flow types or ESlint rules, not both…

Flow doesn’t support Unicode. End of story for me.

1 Like

I don’t remember. I lost track of the state of my test repo. I really need to set aside some time and figure out Flow and Meteor testing, and integrate those into my boilerplate.

How does Unicode figure into Flow? function myFünc(sómeVar: string) { } ??

Yeah me too.

(Initially, I also had some trouble with different typings for client JS, server JS and shared JS)

If you mix and match TS with ‘regular’ JS files, you are in for some pain. It’s best either to go all in or not at all. The reference system of TS is both good and bad in the form it is right now.

For instance, see -https://www.reddit.com/r/typescript/comments/315ae4/newbie_question_is_it_possible_to_slowly/. Quoted, “You can mixe your code, but be careful with the file ordering.”

I tried TS on an old ~3k standalone JS file. I incrementally moved to TS (so a part of it was JS, part TS). That worked out fairly well.

IMO in the long run as more and more people jump on the TS bandwagon and these things come up, the TS team is going to make it more easier to use TS. Right now everything is configurable and that’s a blessing and a curse. Opinionated TS would be nice for the general mass - something, which if Meteor offers, will set it quite apart.

I didn’t know that!

Why is there no talk on the web about this? https://www.google.co.in/search?q=flow+type+checker+and+unicode

How does Unicode sit in with TS right now? I did find this https://github.com/Microsoft/TypeScript/wiki/What’s-new-in-TypeScript#unicode-codepoint-escapes-in-strings