anyone here have any advice for us?
We were very early adopters of Meteor–we had stuff in production back in Meteor 0.6. But upgraded with each new version as we build our app. It was pretty disruptive at times, but on the whole things just seems to fall into place when we needed them. A year and a half ago, my CTO left to start his own thing. Since then we’ve had a few contractors work on the code, but the last upgrade was 188.8.131.52. Now we have a big problem: Atlas is deprecating MongoDB 3.2, so we upgraded the database to 3.6. But after I did that, I found out this version of Meteor isn’t compatible with mdb 3.6, so the database is spewing errors like a hundred times a second.
I asked a contract dev if he could just upgrade Meteor to make it work, but apparently a total mindfuck because we use many old packages which depend on old versions of various libraries. He says we could try and in-line all those packages and pin their deps, but it goes on and one with no end in sight. Here is how the dev explains it:
the problem is, we need to identify dependencies, deps of deps and deps of deps of deps that depend on anything that might block ecmascript 7
in general, browserify and coffeescript are main blockers here.
the main problem is, especially coffeescript is extensively used in quite a lot of old meteor packages that are no longer maintained. the idea is to find some common denominator packages and clone them locally to allow new version of the coffeescript package which does not block.
but the problem is, the packages don’t reveal themselves together. you hit a block, solve it and then hit one or few more blocks, fix them, and hit others.
after each one we fix, we run meteor update to see a new deps tree conflict list.
the problem is, since all our deps are at very very very old versions, it is very hard to identify a sane upgrade path without trial and error.
I am now suspecting that, although this should be done if we want to keep maintaining/running these apps for some more time, it is now going to be much more costly than simply getting ourselves a mongodb 3.2 database.
we could simply get a 3.2 mongo replicaset, deploy it on digital ocean or something equivalent and call it the day.
I know this might sound scary, but belive me it is not. the set up would take maybe a few hours, migration perhaps another few hours, we can set up proper back ups and leave it.
I have mongodb self deployments running in production for over 4 years now. it is not ideal, but might save the day.
I really hate hosting my own stuff, so I guess we could switch to Compose, but it looks like it’s gonna cost nearly 300% more than we are paying today.
Any other ideas? I’m kind of wishing I never build on Meteor. Using all these community packages has created a total disaster for us!