Though I clearly understand there may be performance upsides of moving to async/await, there are undoubtedly numerous older Meteor apps out there that still use fibres due their ease of coding.
So, I am curious how effectively wrapAsync in Meteor 2.16 deals with imported NPM code that may now include async and await keywords.
Are such modules usable in Meteor 2.16 apps, and does wrapAsync help resolve any potential issues of using async/await in Meteor 2 apps? (or does it ‘just work’)
The reason I ask is that I am in the process of migrating several apps from Meteor 2.7.3 to 2.16. I intend to move to meteor 3 in the next few months, but I’m not prepared to do that yet. But in migrating to 2.16, I have had to swap out older previously working but now abandoned libraries (like gm for sharp), that now likely use async/await. Should I be concerned they may not work in meteor 2.17, and will wrapAsync be a useful tool for me to resolve any potential such cases?
We tried upgrading in steps as well but as there are a lot of changes between them sometimes it’s easier to bite the bullet. It’s a (in my view) horrible upgrade experience but in the end you are then at a stable recent point V3 which allows to have easier upgrades after that.
In the end we experienced that otherwise you have to modify the same code multiple times without much advantage. It’s a hard decision but maybe try to run it on a piece to see how things go. Focussing on how the custom Meteor imports work in 2.x won’t make you happy in the long run when you move to 3.x.
You will also experience this with the libraries, some will work at later 2.x versions but won’t be the good solution in 3.x so all time invested in that might be worthless when arriving at 3.x.
Of course if no other option you’ll have to take the steps in between.
My 2.7.3 apps were generally using vsivsi:file-collection which no longer works for mongo 7, a requirement on 2.16. After working hard with a goal to move to Ostrio:Files-Collection (with a lot of patient support from Dr-Dimitru), I abandoned that idea and found edemaine:file-collection which simplified my move. After a few hickups, and support from edemaine, I mostly got all my apps to 2.17 with only one other major roadblock.
My 2.7.3 apps were using gm (graphicsMagick) which forced me to switch to sharp for graphics. But I’m currently stuck there in 3 apps because I dont see how to wrapAsync a series of stream functions required.to use sharp. Without wrapAsync, the meteor method either returns before the image is processsed, or processes the image, and returns nothing. Aaarg!
I’ll probably need to get help to resolve this issue, if I can’t resolve it myself soon.
After working hard with a goal to move to Ostrio:Files-Collection (with a lot of patient support from Dr-Dimitru), I abandoned that idea and found edemaine:file-collection which simplified my move.
This package has not had recent updates. Please investigate its current state before committing to using it in your project.
It seems quite expensive to invest in older packages you know won’t be available in a few months when you move to 3.x.
With the type of tools you use it seems even more important as many of those work totally different with the async await structure and the upgraded node versions. Do not underestimate that node also now is strongly updated. Tools for like graphics rely a lot on it.
If you try to go the 2.7 path then make sure your dependencies at least also have 3.x versions available. Also be aware that the interface of many of those packages changed quite a bit in the upgrade from 2->3.
In Meteor 2, you simply use Promise.await() to call async functions regardless of whether they are in your app or in external NPM modules. No need for Meteor.wrapAsync().
i moved from vsivsi:file-collection (last updated about 10 years ago) to edemaine:file-collection, in order to get to 2.16, because vsivsi:file-collecction doesnt work past mongo 5. The transition to edemaine was quite straight forward, Its an intermediate step so I can migrate to Meteor 3 next but with a stable Mongo.
I look at it a bit different: I see meteor as my tool/version and only look at that. So I do not care much about the underlying versions but just: does meteor run the app properly.