Meteor.js v3.1.1 is out! 🎉

[rjdavid]

@grubba

Meteor 3.1.1 is, on average, ~28% faster, uses ~51% less CPU and ~17% less RAM in a reactive scenario, compared with 2.16.

Meteor 3.1.1 is on average ~19% faster, uses ~28,82% more CPU and ~27% more of RAM in a non-reactive scenario, compared with 2.16.

Thanks for the hardwork

[paulishca]

@grubba

Node upgrade: v22.13.0

npm is now 10.9.2 (from 10.9.0).

[juliandierker]

Great work. I’d love to update from meteor 2.16 => I have a branch ready where latest 3.1.1 is fully installed but somehow I can not build the project. I get
=> Started proxy.
=> Started MongoDB.
=> Exited with code: 7
=> Your application is crashing. Waiting for file change.

I know there were some “strict mode changes under the hood” but I have a hard time to debug this.

[janmp]

Not sure if I remember correctly, I have done my Meteor 3 updates last summer, but I think I had the same problem and deleting the dev DB helped.

[mvogt22]

Very exciting to see significant development around the performance of Meteor to address scalability concerns that after all these years continue to plague the framework.

Performance gains for methods, which I’m sure are utilized more for commercial / production applications than reactivity/subscriptions, will be well received in the community.

[juliandierker]

@juliandierker

hard

@drone1

lot

Thanks for response we did reset local database as well.

[wreiske]

So far have had a great experience with 3.1.1 in production.

I have noticed a lower amount of memory, but a lot more context switches!

[paulishca]

@wreiske

experience with 3.1.1 in production.

Hi @wreiske I am curious now what is the other Meteor version on the graph.

[minhna]

@wreiske

but a lot more context switches

What does it mean? Is that bad?

[nachocodoner]

Thanks for testing, it’s great to see memory usage reduced.

Regarding context switching or interrupts, this seems to be a result of parallelism, right? Since the core code now processes batches in the async queue, it might lead to more of that. I’m not too familiar with this metric. But as a positive outcome, it will also reduce processing time.

I’ll reach out to you privately to test a few things and hopefully gain more insights into it.

[gabsferreira]

We just released a video where I chat with @nachocodoner and @grubba about what we’ve done in this release: https://www.youtube.com/watch?v=tZY6jZGU9Ok

[harry97]

I was about to start missing @leonardoventurini updates. Great job on those video, please keep them coming

[digitalextremist]

The production value of these videos is excellent. Really grateful the investment and effort has been put into this. Goes a very long way. Major congratulations on being able to pull these update videos off.

[hachavbanav]

Thanks for the great job !
One question I have not been able to answer by looking through forums or git…
==> Which exact release of mongodb is bundled with Meteor 3.1.1 (+ where may I find the answer for next release) ?

Best regards

[storyteller]

Meteor 3.1.1 is bundled with MongoDB 7.0.5
You can find the versions in: /scripts/build-dev-bundle-common.sh

[waldgeist]

Thanks for your great work on Meteor! I’m just about to test my whole app manually after my Meteor 3 upgrade, so I decided to use the new 3.1.1 for this.

When I start the server, it shows a lot of warnings like these:

I’m a bit confused, because I thought updateAsync is now the way to go? Or is Collection2 using some low-level Mongo DB APIs here? Is there a fix for this already available?

[Update: There’s already an issue for this here: Triggers deprecation warnings in Meteor 3.1.1 allow-deny package · Issue #462 · Meteor-Community-Packages/meteor-collection2 · GitHub]

Also seeing this:

Yet I don’t know where exactly this is coming from?

[storyteller]

For the util._extend warning that is coming from a dependency. There is a fix for this already merged in 3.1.2.

As for the updateAsync issue I have a PR on that in collection2, but the tests are failing and I’m waiting for feedback to better understand if my fix makes sense.

[waldgeist]

Thanks for the fast response! I skipped Meteor 3.1.1 for now, since I am also awaiting feedback on the roles changes.

[nachocodoner]

@waldgeist

I’m a bit confused, because I thought updateAsync is now the way to go? Or is Collection2 using some low-level Mongo DB APIs here? Is there a fix for this already available?

Based on your stack trace, the issue happens from the collection2 library, which uses an outdated method for configuring allow/deny rules. The problem isn’t with updateAsync as a Mongo operation or any other, but rather with how these allow/deny rules are set up to let client operations affect the server directly.

Previously, both update and updateAsync could be used within collection.allow({ <here> }). This duplication added no value, as allow/deny rules only need a single validator for client operations, regardless of whether the operations are async or sync.

In 3.1.1 onwards, allow/deny validators are configured solely through insert, update, and remove options, which can include async validation logic. We’ve also made additional fixes in our revision of this feature, as happened on this PR: Tweaks on allow/deny rules by nachocodoner · Pull Request #13499 · meteor/meteor · GitHub

Community packages, like collection2, must stay updated with the latest standards. You can use METEOR_NO_DEPRECATION to ignore warnings, even with a regex to target only allow/deny ones. However, it’s good when seeing them to report these issues or fixes for these packages to address deprecations and prepare for breaking changes in future Meteor minor versions.

[nachocodoner]

@waldgeist

Also seeing this:

Yet I don’t know where exactly this is coming from?

Regarding this we have been discussing it on a github issue here, GitHub · Where software is built

We will probably asses to solve this by forking a library used internally that uses deprected way to extend objects.