What's coming in Meteor 1.9?

[methodx]

What are the plans / roadmap going forward?

[rjdavid]

There is a chance that the current 1.8.1 beta will become 1.9. The move from cordova-android 6.x to 7.x in 1.8.1-beta.15 introduced some breaking changes

[storyteller]

I don’t think so. I think 1.8.1 will remain as is. If that is the case then I expect Node 10 for 1.9.

[techplex]

You can always check the history file in the meteor repo: https://github.com/meteor/meteor/blob/devel/History.md

The Roadmap.md file has a high level set of goals: https://github.com/meteor/meteor/blob/devel/Roadmap.md

[morganpattens]

From the 1.8 release blog post:

“What’s next”:

• Node.js 8.12.0, but actually
• An officially supported typescript package
• More flexible meteor create options, e.g. --apollo
• Compiling compiler plugins after installation
• A slimmer version of the autoupdate package for minimal Meteor apps
• Installing Meteor packages from npm?

Probably just a subset of that. I’d very happy with official Typescript support.

[efrancis]

The Roadmap.md file has a high level set of goals: https://github.com/meteor/meteor/blob/devel/Roadmap.md

Up to date as of October 9, 2018

[techplex]

Thus the goals haven’t changed since October 9th 2018.

[storyteller]

Yes, since that is around time when 1.8 came out. Why should there be an update when there wasn’t a major release since?

[hemalr87]

Would very much love tight Typescript support

[a4xrbj1]

I’d love to see MongoDb multi-document transactions support. This is critical for small (and big) companies like us. I don’t understand that no one else is asking much for it.

Can only mean that that companies have turned their back to Meteor with MongoDb.

[alawi]

Do you mean a
MongoDB ACID transactions? That’s already being asked and it’s supported I think.

[a4xrbj1]

Yes, and It’s not supported, please see the thread

[alawi]

I did look at the thread you started and it seems that it does work using MongoClient instance, so as far as I can tell yes you can use it, but I guess you want it through meteor/mongo. Also, if big/medium size companies are using/waning it, I’m not sure why none of them contribute a PR for it, after all it is open source.

[pmogollon]

I can tell that it does actually works correctly, you just need to access the rawCollection and mongoInternals for the mongodb client.

I havent had any issues with it.

[sakulstra]

We are investigating ways to make it possible to move some parts of Meteor core onto npm without making the installation process more complex.

Is there any update on this? I think i read somewhere that this won’t be possible in the near future due to how tinytest works and all internal package tests relying on it (can’t find the thread/issue though - it was a long time ago, when this first appeared on the roadmap in 1.3).

Wondering if the solution - refactoring tests to jest - used by aldeed in https://github.com/meteor/meteor/pull/9603 (fun fact, this pr has it’s 1 birthday in two days) as https://github.com/reactioncommerce/random is the way to go? For me the biggest pain point with meteor still is testing and especially integrating meteor in test-tooling when meteor is just a tiny part of the big application picture (we spend hours mocking/stubbing but still the meteor part is the least tested in our application).

[captainn]

There are features in Meteor’s package system that makes a move to npm less than optimal. Modern builds would not be as efficient, unless some of the features of atmosphere were ported - such as delivering uncompiled sources, and probably also separate entry points. Meteor devs have been reluctant to extends npm this way (or maybe npm is not really set up for that, I don’t remember). We’d also lose other features like including non-js automatically, auto configured build plugins, etc. Unless something has changed I’m not aware of (very possible) I’m not sure I see how to move to npm without losing some of the benefits of modern bundles, and a few other things.

[a4xrbj1]

Also, if big/medium size companies are using/waning it, I’m not sure why none of them contribute a PR for it, after all it is open source.

I’d love to hear from any small/medium sized company that is indeed using Meteor. Apparently there are 17000 active websites with Meteor in the World right now, so could someone raise their hands?

I’d be keen to have a discussion on how we and other small businesses are using Meteor.

[a4xrbj1]

but I guess you want it through meteor/mongo.

You’re guessing right. We do have over 1200 functions in our server code, changing way over 1000 MongoDb commands isn’t something that we want to do, especially being so close to launch (it would mean a big delay).

Yet, we do need the ability to rollback multi document transactions in case one of the insert/update/remove is throwing an error (or something else in the code).

[captainn]

I’ve got a couple of Meteor sites in production, all using Mongo through either ddp-pub/sub or methods. I haven’t switched to Apollo yet - I’d like to, but there’s a lot to set up with it. I have some ideas on how to make that easier in Meteor 2.0! It involves sort of deprecating pub/sub (or at least downplaying it’s role in most cases where real-time response and push is not necessary) in favor of a connector model (especially applicable to react apps), even with MiniMongo. Once that pattern is established, it should be relatively easy to convert or migrate over time to Apollo, since all that data code ends up in one place.

I have mostly avoided issues like ACID transactions (in favor of rapid shipment), although I think my containerized, almost flux data flow model would help there (since I’m not using or worried about pub/sub, going directly to the data tier to set up transactions should be easier). What other issues do you want to discuss?

[a4xrbj1]

What other issues do you want to discuss?

For starters, we have written up what we’ve found out so far on how to get MongoDb multi-document transactions going: Provide access to the MongoClient for transactions & change streams #311. It would be good to have more support to get this project on the roadmap for Meteor because right now it’s not on their roadmap (no one is assigned/no milestone, nothing).

But I’d like to point out more necessary code changes should you follow the temporary solution that is currently the only possible route:

• Create named exports for all collections that will use transactions using Collection.rawCollection() and export them

• Add a call for a function that generates a string base _id using Random.id() for insert functions to and attach it to the object

• Change all chain of execution (calling functions) to include transaction session variable from top invocation to lowest one

• Change code for updates const numUpdates = dbCollection.update() so it works with currently huge list returned

• Change .map() queries to use .toArray() at the end so we get an array of objects

• Refactor code that uses .fetch() to use .toArray() if they are using rawCollection only

That’s a lot of refactoring when you have 69,000 LOC for your server app only!

I’m pretty sure most of that could be avoided if MDG would include multi-document transactions into a future release.