I have an issue updating Meteor and wanted to get opinions from the community. I’ve been using jalik:ufs gridfs to handle media uploads but the package is not receiving many updates, thus it will only work with Meteor 2.1. Has anyone had this issue? Did you migrate to another package? How would I be able to maintain the urls to the files uploaded using ufs?
Is there a known specific functionality of the package that prevents it to be used on other versions?
Is this just a simple version constraint? [How to fix] Package constraints error when upgrading to Meteor 2.3+
1 Like
This is the issue that has me stuck at Meteor 2.1 as the package will only work with npm-mongo 3.8.1.
And when I try to jump to 2.6, I can’t even upload or read images anymore but I haven’t delved into why yet.
With this in mind, it may be time to transition to another package but wanted to know if anyone has migrated before and what’s the least painful way of doing so.
Try using 2.5 first.
But the general recommendation is to apply one major update at a time while using the meteor changelog as a guide
Yes, I did a stepped upgrade all the way to 2.6 but realized this issue at 2.6 when I tried to upload which is when I realized I had to roll back to 2.1. At a crossroads now, do I continue in with jalik:ufs or move to another package such as GitHub - veliovgroup/Meteor-Files: 🚀 Upload files via DDP or HTTP to ☄️ Meteor server FS, AWS, GridFS, DropBox or Google Drive. Fast, secure and robust.. As well, how would I be able to transition and retain my old uploads via jalik:ufs gridfs?
You will need to do a migration of existing files to the new package i.e. go through all records and reupload using new package. A bulk migration might be possible but you need to know how the old and new packages work behind the scenes.
And after migration, I guess I could just reroute requests to the old url to the new url via middleware as long as I save the old ID and collection name?
The urls created by jalik:ufs were https://mydomain.com/ufs/:collectionName/:fileId/:filename
It is just a question of taking on the technical debt now (do the data migration) or handling the technical debt in the future (reroute)
From experience, I prefer data migration to creating a middleware just specifically to handle the reroute. That middleware is extra processing and extra test cases that you need to keep as long as your app is being maintained.