why not just let us use whatever node version we want. why do we have to lock into v4.
Especially since Apollo desires v5 
Node 4 is still LTS so it makes sense to support it. Node 5 doesn’t have a future (and won’t be LTS), and Node 6 is so new that certain npm packages that Meteor relies on break with it (see https://github.com/meteor/meteor/pull/6923). So for now it makes sense to stick with Node 4, but Node 6 support is coming.
This is impractical as we’d need an n^2 matrix of architectures to node versions.
1 Like
We’re hoping to have a beta that includes Node 4 within the next few weeks. Not sure on a timeline for Mongo 3.2 yet but we’re making solid progress, you can follow along here: https://github.com/meteor/meteor/issues/6957
3 Likes
This is the only way we could work this out.(and even less liability to MDG). It would be nice if we have done this before since most of the users already have these build tools setup.
3 Likes
Mongo 3.2 is long available, I’m running it without problems for months. Only difference is that it becomes the standard version for everyone. If you run it on WT, the space implications are tremendous. Have seen that it takes only 1:25th of the previous space, as older Mongo keeps the file size per collection at it’s maximum size, even when you delete all docs in it.
It’s also faster but that’s not so apparent as the space saving
3 Likes
Is the aggregation pipeline by any chance something that feeds into a result that ultimately is reactive? [hopeful expression]
You can make it real-time by yourself now. But you need do extra steps.
The book Meteor in Action talks about this.
With Node 6, coming, will you consider to use directly Ecmascript 2015 with no transpilation? WebKit has 100% coverage, Chrome and Firefox 95%, Explorer is a dead fish for Academic applications and Edge is doing well as well. The only thing needed will be async/await polyfill. Would be great to finally comfortably debug apps in native code! What will it take in Meteor? Will it be only to remove the “ecmascript” package?
They can remove transpilation when they move to node 6 for server side code but they cannot remove transpilation for browser as people use all kind of browsers not just the cutting edge.
It’s all right when developing mobile apps or web apps in closed “company/academic” environment where you can assure the use of the latest browser. Which in my case is ok for 10000s of users. I really can’t wait to ditch babel 
Is there any problem with debugging with babel currently?
There are some issues that i do face when using async/await on client.
sashko, yes, the source maps never really work … the async code keeps flying around, setting a breakpoint is a pain … and debugging transpiled code is …not pleasant to say at least. Also, sourcemaps slow down the whole debugging experience and webpack compilation functionality .
Good stuff Well done, MDG!
1 Like
With the update to node 4 does this mean arm devices will be supported. I’m currently running meteor on a VPS and doing all my work remotely with my Chromebook. Having an arm version would be great.
Cool. Respect to MDG for this release. It’s ‘nothing to write about in press-release’ or ‘talk in conferences’ release but ‘very expected by community’ release. If 1.5 will also include something like Webpack and improved build times, I bet every community member would be have +300 happiness and +500 to confidence in Meteor future.
And if your PR guy will shed a tear about absence of ‘cool news’ I guess he will be amazed by the influx of new members - and that would be the NEWS.
6 Likes