Official TypeScript compiler coming to Meteor

So after @benjamn finished working on Apollo Federation he is back with rewriting core modules of Meteor into TypeScript and now creating a compiler for the rest of us. 1.8.2 is sure going to be quiet an important release:


Yeah, it’s very good to see Ben active again on Meteor.

It would be very good if MDG did an update on Roadmap and next goals for Meteor.

I hope to see tree shaking soon :wink: It would be extremely valuable to my company


Awesome news! Just started up a CRA typescript project to get the hang of things, and if it lives up to the hype, keen to migrate to it on all existing projects too.

1 Like

Is it possible to use TS with 1.8.0?

1 Like

Agreed, I think official TypeScript, tree shaking and client only refresh using the dependency tree (without the client folder and from within packages) are great candidate for upcoming releases.

Ben seems on the roll, so hopefully Meteor will get more love :slight_smile:


I don’t use TS but I guess the answer is yes given that we already have barbatus:typescripr compiler on Atmosphere.

1 Like

I mean official package from meteor. At first quick research it doesn’t have a problem to use typescript compiler with prev version of meteor


Awesome news, seriously, was waiting for it for quite a while!
Thank you!

I am still using the (fantastic, thanks @yorrd) adornis plugin for the moment, as I don’t want to mess with my custom tsconfig.json and ts version.
As soon that we can use our own tsconfig and our own ts version (in node_modules) I am definitely going to switch!


I’m very excited to have official TS support. I agree with @alawi

that tree shaking and client only refresh using the dependency tree (without the client folder and from within packages ) are great candidate for upcoming releases.

1 Like

For anyone interested here are the slides from @benjamn presentation about TS in Meteor from Meteor Night:


I thinks this is awesome, and as is stated in the deck, is a huge opportunity for us, the community, to get our hands dirty and understand how Meteor build system actually work so that we are able to continue contributing.

Im all in!


waiting for a video too)

I’m really excited about bringing TypeScript to Meteor, but no-one’s mentioned this slide:

  • Meteor’s data system should be database-independent, rather than tightly coupled to Mongo

  • Making everything reactive and real-time by default is great for rapid prototyping, but also a source of scaling problems for Meteor applications

  • If Meteor becomes more agnostic about the sources of your data, we can’t keep calling its client-side query language “Minimongo”

  • As a company, we should get out of the business of shipping monolithic all-or-nothing frameworks

nor the homage to next.js.

IMO, both those slides seem to provide an insight into @benjamn’s thinking of the direction(s) Meteor should develop in. On the one hand remove tight MongoDB coupling and (seemingly) provide better integration with Apollo: by extension a more attractive path into wider adoption of Meteor. On the other, more of the “expected” functionality of a JS/TS development platform - again providing a more attractive developer offering. These would be huge changes.

Ben also mentions Meteor’s commitment to backwards compatibility and its (possibly over-zealous) zero-config approach. Now, I love those aspects of Meteor, together with its rapid prototyping, but I’m doubtful that all the potential changes on the table would be compatible. Perhaps, we’re looking at a future Meteor 2 and the clearest signal of all that Meteor is still the right tool to run with.


Just hope that any Meteor Apollo client integration plays well with frameworks other than React (thinking about Vue here)…

1 Like

It should. Apollo isn’t tied to any view layer. Those are separate things. There may be a small glue code for each view library, to make it easier to hook them into Apollo reactivity; a simple HoC for React, for Vue, for Angular, etc.

Even without glue code, it’ll be simple enough to listen to changes in a GraphQL query, then manually call setState or forceUpdate on your React component to tell it when to update. That’s basically all the glue code will do.

1 Like

Finally really good news from MDG! Really waiting for it.


If you’re interested in following @benjamn’s typescript work, you’ll find it merged into 1.8.2.

Update. It’s now in the1.8.2-beta.16 release, so we can get to play with it :smile:



It’s a small step for Ben a big step for Meteor’s Community :slight_smile:


:+1: Very topical :smile:


Are there any stats on how many devs know TypeScript vs. vanilla JS?