Help I'm trapped in an old version of Meteor

help
1

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 1.4.4.1. 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!

2

You could always fork the 3rd party packages to your packages/ directory and fix whatever issues exist in those packages.

3

As a stop gap, you could:

  • Migrate to a Mongo 3.4 database with Atlas (which they’re going to do automatically for all Mongo 3.2 customers in Sept.).
  • Upgrade to a Meteor version that doesn’t include the newer Babel 7 changes, which is the main cause of all the issues you’ve outlined. So upgrade to Meteor 1.5.4.2 for example.

With the above, you should be able to buy yourself more time. That being said, at some point you really should consider updating across the board. Meteor 1.5.x still uses Node 4, which has been EOL’d. Yes, it will be a pain to bring everything up to date, but this isn’t a problem that’s exclusive to Meteor. Application dependencies have to be continuously kept up to date (as much as possible) in any Node based app, or this problem will eventually rear its ugly head.

I know it sucks, but I can assure you the grass is not greener on the non-Meteor side of the fence, when it comes to updating the dependencies of older apps. Just try running npm install on a 3 year old Node/non-Meteor app that hasn’t kept its deps up to date … :scream:

3 Likes
4

mlab still supports 3.2 (actually even 2.6 for dedicated servers)

5

How large of an app, and are you looking for devs to help with the upgrade?

1 Like
6

it’s large and complex with a lot of integrations. It’s kind of like an ERP system with cart, orders, payments, purchasing, receiving, fulfillment and shipping modules. There are actually three apps: two client apps and one backend (admin) app–all working off the same MongoDB.

Does anyone know where is the first (oldest) version of Meteor which officially supports 3.4? Is there a list or diagram somewhere?

7

Here’s an untested idea. Clone Meteor and checkout the release branch you’re using (or download the release directly). Copy the mongo package to your packages folder and update for the latest MongoDB npm package.

As far as I know the methods used should be compatible with an older Meteor version.

1 Like
8

does @robfallows idea seem plausible to you @hwillson

9

What a tragedy that these architectures can’t be upgraded without catastrophic failure. How is that possibly a good idea? What’s wrong with the computing community in creating these monstrosities? Shouldn’t components and libraries be able to survive an upgrade to the host app which they serve?

10

I typically will search the changelog for mongo or mongo 3. to scan down the list of supported versions that they announce, but I don’t think there’s a compatibility table anywhere.
https://docs.meteor.com/changelog.html

Have you seen this on the the changelog for 1.7? not sure if it’s relevant to your errors:

NOTE: After upgrading an application to use Mongo 3.6.4, it has been observed (#9591) that attempting to run that application with an older version of Meteor (via meteor --release X), that uses an older version of Mongo, can prevent the application from starting. This can be fixed by either running meteor reset, or by repairing the Mongo database. To repair the database, find the mongod binary on your system that lines up with the Meteor release you’re jumping back to, and run mongodb --dbpath your-apps-db --repair. For example:

It’s definitely a mess >.< I’ve learned the hard way over the years that adding and 3rd party dependencies is adding technical debt to your codebase. Like real debt, you get the benefit of speed up front but pay later with lack of support, incompatibilities with your app, dealing with that packages dependencies, etc… The Meteor ecosystem really seemed to favor gluing leggos together as opposed to software engineering and I felt like that made it even worse.

2 Likes
12

Mongo 3.4 support was officially introduced in Meteor 1.6.1. If you’re looking for a quick fix though, you can’t go to 1.6.1 since it’s the Babel 7 issues that were introduced in Meteor 1.6 that are conflicting with your older packages. That being said, Mongo 3.4 still worked with versions of Meteor before 1.6.1, it just wasn’t included with the Meteor build Tool until 1.6.1. Many people were running with Mongo 3.4 in production way before Meteor 1.6.1. That’s why I recommended upgrading to something like Meteor 1.5.4.2 for example (again, as a quick fix). You’re then at least getting a somewhat newer Meteor version, and you should be able to work with the Mongo 3.4 database without too much difficulty.

There are ways you can make an approach like the one @robfallows mentioned work (that’s the power of Meteor’s package system - you can clone and override just about any of its internal packages! :slight_smile:). Heading down this path will give you an even larger maintenance headache in the future though (especially if you don’t have someone on your team who can actively support this solution), and is not something that should be considered lightly.

Honestly, your best bet is to focus on getting your technical debt paid down now. If you don’t deal with the out of date dependencies sooner than later, it’s only going to get worse. If you’re looking for the cheapest and easiest solution (that is again adding to your technical debt), then as @rjdavid’s mentioned, https://mlab.com still supports Mongo 3.2 (and are way cheaper than Compose).

3 Likes