What's coming in Meteor 1.9?

methodx · January 18, 2019, 5:20am

What are the plans / roadmap going forward?

rjdavid · January 18, 2019, 5:49am

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 · January 18, 2019, 8:06am

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 · January 21, 2019, 5:23pm

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 · January 22, 2019, 10:12am

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 · January 22, 2019, 5:52pm

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 · January 23, 2019, 3:23am

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

storyteller · January 23, 2019, 7:55am

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 · January 23, 2019, 8:00am

Would very much love tight Typescript support

a4xrbj1 · January 28, 2019, 4:53am

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 · January 28, 2019, 7:37am

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

a4xrbj1 · January 28, 2019, 11:49am

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

alawi · January 28, 2019, 12:41pm

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 · January 28, 2019, 1:15pm

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 · January 28, 2019, 4:54pm

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 · January 28, 2019, 7:54pm

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 · February 2, 2019, 8:41am

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 · February 2, 2019, 8:45am

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 · February 4, 2019, 9:37pm

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 · February 5, 2019, 6:44am

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.