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 https://github.com/meteor/meteor/blob/devel/Roadmap.md#meteor-roadmap and next goals for Meteor.
I hope to see tree shaking soon It would be extremely valuable to my company https://github.com/meteor/meteor/blob/devel/Roadmap.md#page-load-performance-improvements
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.
Is it possible to use TS with 1.8.0?
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
I don’t use TS but I guess the answer is yes given that we already have barbatus:typescripr compiler on Atmosphere.
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.
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)…
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.
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
Great…
It’s a small step for Ben a big step for Meteor’s Community
Very topical
Are there any stats on how many devs know TypeScript vs. vanilla JS?