1.7.0.1 upgrade bombs [SOLVED]

help
1

I just wish ONCE I could perform a Meteor version upgrade without the entire application BOMBING and spending wasted days fixing things, but alas that never seems to be the case. After being bitten by the Mongo change and scrambling for a way to run the command (hint you need to fire up mongod from the 1.6 line):
db.adminCommand( { setFeatureCompatibilityVersion: '3.4' } )
from a system that was at 1.7.0.1 which of course would not start, followed by the repair command:
~/.meteor/packages/meteor-tool/1.7.0_1/mt-os.linuxin/mongod --dbpath .meteor/local/db --repair

After this I was able to get meteor to start, but still no working application. Instead an admin package we use that has not been touched in a LONG (months, maybe years) time now bombs on the following code:


const DashboardImpl = () => {
  this.items = {};
  this.dep = new Tracker.Dependency();
};
export default DashboardImpl;

DashboardImpl.prototype.set = (key, value) => {
  this.items[key] = value;
  this.dep.changed();
};

With the exact error in the browser console being Uncaught TypeError: Cannot set property ‘set’ of undefined. As mentioned code NOT touched, just the upgrade.

Looks like I am in for the latest roller coaster ride, please grab a seat with me :slight_smile: Thanks for any help in advance, appreciate it!

2

As a followup to my own post, the following code resolved the issue:

export default function DashboardImpl() {
  this.items = {};
  this.dep = new Tracker.Dependency();
}

DashboardImpl.prototype.set = function dashboardImplSet(key, value) {
  this.items[key] = value;
  this.dep.changed();
};

What next…

3

Arrow functions do not have a .prototype property, and thus cannot be used as constructor functions. This worked previously because arrow functions were compiled (by Babel) to normal function(){} objects, which do have a .prototype. This code should not have worked before, and the fact that it did seem to work was an unintended deviation from the ECMAScript specification on the part of Babel, and something that you would have encountered in any project that uses Babel, once you started using arrow functions natively.

We don’t promise that meteor update will be seamless, just that it will be worth your time. We also don’t force you to use the latest version of Meteor, though we strongly encourage you to upgrade at some point, since the latest versions are where the exciting changes are happening.

Most web frameworks don’t bother to provide an upgrade path that maintains any kind of backwards compatibility. You just never update, or if you do, you might as well start the project over from scratch. I realize it’s hard to know what to expect from meteor update when you don’t have many other reference points, but I would recommend taking more of a we’re-in-this-together attitude towards the process, because we are!

I would also suggest cross-posting questions like this on the GitHub issue tracker, because we probably would have seen your question sooner.

11 Likes
4

Oh, and while you’re paying attention to this code, consider using a class instead of a function!

export default class DashboardImpl {
  constructor() {
    this.items = {};
    this.dep = new Tracker.Dependency();
  }

  set(key, value) {
    this.items[key] = value;
    this.dep.changed();
  }
}
3 Likes
5

@benjamn To extend on your answer a bit. Keeping a codebase healthy means continuously improving your code, updating dependencies and other things. Expect issues in your code to show up on any update…

Also when I hear people mentioning that code that they haven’t touched for a long time ‘suddenly’ breaks after an update - I would not be surprised. Continuous refactoring is a thing guys!

https://martinfowler.com/books/refactoring.html

2 Likes
6

Thanks for all of the feedback and the suggestions moving the code forward. I suspected that the cause of this was the change to native just thrown for a loop because as mentioned this module does what it needs and therefore has not been changed in quite some time. This on top of the Mongo upgrade bug where I found a tracker that basically said - yep it breaks people can fix it and we will mention it made for a rough day. After these though, I have to say things are working well so far, need to do some more testing.

As far as other frameworks not providing any upgrade path, that seems a bit over exaggerated. May of the web based frameworks we use have provided upgrades that have been smooth (or at least were when we were using the tools).

I apologize for the frustration and do truly appreciate the tool that meteor is. I jumped over here after spending a bunch of time coding without any real framework (unless you consider jQuery a framework), then over to Wakanda for a while and now here where I have been overall happy.

@cloudspider - Yes, continuous refactoring is a thing but this module does exactly what we need it to do and our time is better spent performing this on the “active” part of the code base which happens.

Thanks and back to development…

7

I understand your frustration, and I think it’s a legitimate request for help, but…

I just wish ONCE I could perform a Meteor version upgrade without the entire application BOMBING

To say that as if Meteor is at fault is simply shifting the blame from your own backyard. You know, it’s sloppy code that breaks. And prototype on an arrow function is sloppy, no matter how you dress it. That should’ve been refactored before long.

Since version 0.49 (2013, I think) I have yet to perform a Meteor update, and have our (otherwise huge and complex) app bombing. Once.

Edit: Should’ve said ‘bombing because of Meteor’. Because of us… many a time.