Hi,
I’m making my first customer meteor/vue/Vuetify web/Android/ios project, but need input on how many “hours” to take for updating the meteor project every month/year/week?
Frankly my Meteor update sum didn’t exceed 4 hours/6 months for relatively large code base. Meteor, for me, has been really backward compatible and the beauty is that babel, node and mongo are all being updated behind the scene, so that’s time saving on staying up to date with the node ecosystem.
Most of the migration/update has been spent on React (and React 17 is coming soon which will be yet another major update) and the related NPM packages. While I appreciate the move fast, break things mindset, it feels like full-time job just upgrading and migrating react components!
Hi @thorus
I’m going through exactly the same thing at the moment.
I’ve decided on a one-off fee to build/deploy/submit etc, then a $ per month subscription for updates/db-hosting/backups etc (anything I can think of that gets them asking “You do all that?”)
Very early days yet, but feedback has been positive.
Good luck!
Thanks for your input.
How often do i need to update the Android and IOS app meteor code?
Just a word of warning. I’ve found Meteor good in the past with backwards compatibility making updates easy, however the latest change from 1.6-1.7 was extremely hard, it’s taken us about 3 months to get to the point where we’re comfortable doing the upgrade. Not entirely due to the update itself (though partially), but due to far reaching implications within our code base. Several packages we used (all relying on coffeescript) had to be either manually updated or replaced. Then, with 1.7.0.* we weren’t able to build two of our projects due (presumably) to errors in the babel compiler. We’re now forced onto a beta version of 1.8 as there are still build problems in 1.7.0.*
The worst part about this is that sadly, the upgrade that caused most of the issues wasn’t 1.7 but 1.6.1 - not even a major release, so it’s hard to determine when a “difficult” update will come.
Regarding IOS/Android apps - you’ll have to update them in the app store whenever the cordova version changes, or the version of any cordova plugin changes (unless you’re comfortable with the cordova compatibility version environment variables.
The apps will continue to work even if you don’t do this, but wont receive HCP.
I’m curious could you elaborate on the challenges faced? What was the breaking change?
The big one was meteor files, secondarily was an easysearch package (I forget the name) which we just dropped and changed the way we handled that part of our searching.
The third one was all the testing stuff - we’d been using practicalmeteor, which I know is depracated, but switching to meteortesting caused problems as well, essentially all our unit tests stopped working. We’re not sure why (and are working to fix them now) it was to do with load order.
We’re probably over reliant on packages, particularly kadira, collection-hooks and simple schema dont seem to play nicely in combination with each other, but particularly so when you then also add a mocking package like hwillson:stub-collections
Thanks for sharing your experience but frankly I’m still puzzled hence my curiosity, like I said, we had very smooth migration path from 1.3 all the way to latest with complex code base
I’m not sure what you mean by that, I’m guessing it’s the import syntax but that’s ES6.
That’s not Meteor really, that’s a third party package, in react world, I lost count of how many packages we had to fork and maintain, it’s just the nature of the Open Source ecosystem.
We use practicalmeteor as well, the only issue we had has to do with coffeescript and babel, which was resolved here.
We use all those packages and they do work with each other. The only issue we had with regards to updating and backward compatibility is migrating simple schema to the NPM package and changing few schema syntax (pertaining to lists) due to breaking change in simple schema, you can find the change log here.
Again, none of the staff you listed here is related to core meteor aside from the Meteor files, which I’m not clear what exactly you mean by that. Our experience with core Meteor update has been, run Meteor update command on a branch, report any issue to github, issues get resolved, migrate to production.
First off. Meteor is excellent, and yes - all the way up to 1.6 our upgrade path was quite easy. However, upgrading past 1.6 (even to 1.6.x) has caused us several problems.
The biggest single problem is that we still can’t build our projects with 1.6.x/1.7 - this issue might be the same as ours (it reads a little differently). What we found was the compiler was a little aggressive at fixing code like this:
if (whatever) {
const something = aFunction(() => {
use(something);
});
}
It replaces it with
if (whatever)
const something = ...
which is invalid.
The ostrio:files package was another problem. The coffeescript upgrade stopped this package from working in a number of places. I know almost nothing about coffeescript, and didn’t have the capacity to figure out exactly what the problems here were. We’d also forked the package to deal with some problems (related to security and reliability) we were experiencing. Unfortunately I can’t share what these are until we complete our upgrade to remove the dependency. We weren’t willing to risk upgrading to the latest version and possibly losing our changes, or having something else break here. Unfortunately, the coffeescript upgrade caused things to break in unexpected places. e.g., most of the code would run fine, but specific things would break. It’s likely that these areas would be obvious to a coffeescript expert.
Regarding Kadira, collection-hooks and simple schema. Yes, they play nice with each other in the sense that they can all be installed. But if you dont have the load order correct (something we’re still working out) you’ll find that either your hooks dont fire, your schema doesnt get validated (sometimes different results on client and server) or kadira doesnt track the DB calls. I’m not entirely sure that these problems were related to the upgrade (i.e., they may have existed before but been excaserbated by the upgrade), but what WAS related to the upgrade was the practicalmeteor package, and specifically interactions between it, the hwillson:stub-collections package and other packages that hook into a collection (e.g., those above). For example, our test suite contains around 2000 tests, all of which were running prior to the switch. Upon switching, almost all of these tests didn’t run (not failed, simply didnt run). We’re still looking into why this was the case.
So to summarize, the babel compiler was a core issue, the remainder were all package issues, caused by a core upgrade of coffeescript. However, my understanding of the question wasn’t that it asks how difficult is upgrading meteor in a project containing no packages, but rather how much time should be budgetted for upgrading an existing project. While the packages aren’t part of meteor core, if a meteor upgrade breaks a package, thats something that will need to be either reported to the package maintainer (blocking your upgrade until a fix is issued) or will require you to fork and maintain the package yourself, or requires you to replace the package. All of these take time which should be counted towards how long the meteor upgrade took.
I expect everyones update experiences differ, depending on the style and complexity of the project and whether the project is currently under development (i.e., new features being added). I suspect that our upgrade path is more complex than it needs to be due to:
My purpose here was really only to present a counter-point to your “4 hours in 6 months” comment about upgrades. I wish ours were so easy!
I really appreciate this response, since it helps to shed the light on same of the blind spots we might have. It seems you guys have really complex project going on!