The collection2 package is triggering lots of deprecation messages both on client and server in Meteor 3.1 (e.g., using updateAsync instead of update as the key) – is there any way to disable these messages?
I’m using version 4.0.4 and I don’t see those messages. What is your setup?
Ah, I think maybe it was added in the 3.1.1 beta! I’m using collection2 version 4.0.4 as well.
I already filed an issue for it
3 Likes
contact with support for this issue.
We’ll provide a new environment variable to ignore these warnings as booleans, by default these will show. I’ll likely add a regex option for pattern-based ignores.
4 Likes
Ideally collection2 should not trigger these so that we don’t have to use another env var and another regex. Philosophically … is kind of finding a problem for a solution.
I agree, and we discussed that in our conversation. However, for developers relying on certain packages, it can be frustrating to see these warnings repeatedly during daily work, especially if they aren’t experts in a specific community packages. By default, these warnings are shown to encourage reporting issues or contributing fixes. Allow them to disable the warnings with an env can improve the developer experience, allowing more focus on the meteor app’s business context. In Node, similarly, there’s an environment variable to manage deprecation messages (–trace-deprecation).
I would personally want to make it frustrating for those users :)).
I think the solution for DX frustration is reporting these and/or fixing and not hiding the messages.
I would like to fix this for Collection2 which is a widely used package. I do not use client side methods and if I could understand what it is that I need to to for Collection2 I would gladly push a PR. If the same mechanism applies to the other packages I can invest some time in this direction.
"[DEPRECATION] deny: The “updateAsync” key is deprecated. Use “update” instead. "
Is this just a cosmetic update to do the actual renaming on the client part?
1 Like
We should encourage contributions and that is why they will appear by default. If the new env isn’t set, the warnings will keep appearing. We could also show a log with a note about ignored deprecation warnings, visible once on app start.
Enabling the env is a small effort to improve experience, similar to how Node handles it. If devs ignore warnings, they risk facing a major breaking change once deprecation is complete, causing significant issues later. Like in life, ignoring risks won’t prevent them from appearing later. When they do, the frustration is the most, the decision falls on them.
What do you think about the changes on this matter?
I added a PR with the changes.
Looks great – thanks!
Is this just a cosmetic update to do the actual renaming on the client part?
Currently, both updateAsync and update were available as allow/deny rules. We identified an opportunity to merge them, enabling update to return promises or behave synchronously, as needed. So updateAsync will be completely removed in the next minor. Additionally, issues with these rules were addressed to correct bugs by expanding test coverage.
More details on: Tweaks on allow/deny rules by nachocodoner · Pull Request #13499 · meteor/meteor · GitHub
You can disable deprecation warnings in Meteor by setting the MONGO_OPLOG_URL environment variable to an empty value or setting METEOR_DEPRECATION_WARNINGS=0 in your environment. This should suppress most of the deprecation messages.