We specifically always call our Mongo driver methods in the format db.collectionName.update (saving the collection handles onto a db object as a form of pseudo-namespacing), which makes it a lot easier to tell the difference between db.collectionName.update vs someOtherObject.update. But I recognize that this is an assumption we’re making based on how we define our collections, so it might not work in other codebases.
You’re right, in our codebase, we don’t use db.collectionName. syntax, we always use exported collection variables. In my script, I can open the exported file, look for the variable, if it came from new MongoCollection() init then it is a mongo collection.
But it won’t work if you do something weird likes changing the variable name before export, etc.
I believe Meteor needs to change that wrapper to be async function then change it’s boot-loader to Promise.await it. Things get a bit muddier since meteor also converts await to Promise.await
We were initially planning to release it in a Meteor 2.x version, but supporting top level fiber code in a backwards compatible way, and trying to create a spec compliant implementation of top level await that uses Promise.await seemed to be incompatible, so we are releasing it in Meteor 3 which uses native async/await instead of Promise.await. With enough time and effort I think we could have gotten it to work, but it doesn’t seem worth it with the latest plan for removing fibers.
Top level await only enables using await outside of any function. If you use await inside a function, the requirement for the function to be async still exists.
It isn’t native top level await. Like ES Modules, it is implemented in reify. The PR for that part is at Top level await by zodern · Pull Request #4 · meteor/reify · GitHub. It tries to be spec compliant. When testing how compliant it is for the timing and order it runs modules, it is equivalent to webpack and v8, and significantly better than the other bundlers I’ve tested.
Meteor will still need to support environments for a while where using native module isn’t possible or has downsides compared to using reify. Next year I want to see if there is someplace we could start using them - maybe the meteor tool, or build plugins, or at least parts of the server.
By checking changelog, I don’t see the new core async function since 2.10 but I’m not sure about the core packages.
Your idea about including migration for common packages is very good. I’m thinking about that.