Managing Cordova Dependencies across Meteor versions is a nightmare

help
1

Is there anyway we could get some insight into how dependencies in Cordova packages can become an issue with upgrading across Meteor versions.

I’ve just upgraded to 1.6 and i’m filled with regret. I definitely still have a lot to learn, and I know i’m probably not managing everything correctly, but i feel that everyone tries to encourage fast adoption of the latest major Meteor versions, but if you are not comfortable with dependency management or manipulating build directories etc… that you should be very very very cautious about upgrading Meteor.
Especially if you have a stable app ready for production. Unless anyone can tell me why i’m wrong? I sincerely hope i’m wrong or missing something important. Which is almost definitely the case.

After a day of scanning the internets I find that… it’s easy to see that this has been an ongoing issue for many developers. Often posts on Cordova issues have zero replies or dozens of thumbs up and no solutions proffered or vaguely documented circumstantial fixes/hacks/patches…
basically there seems to be a lack of a coherent strategy from anyone official.

I’m not saying it has to work out of the box… Cordova is its own beast. But if Meteor aims to truly support cross-platform development, as it claims, then this is an issue which deserves more focus, and at the very least an entry in the Guide on how to deal with issues which may arise when upgrading

Stack Overload is filled with threads closed due to the lack of reproducible issues. That’s convenient for developers looking to close off bug threads, but it’s no help to those of us who have chosen to use Meteor for anything but a website.

this is a fun chain of links

These are just a quick sample of people with issues in this area.

anyway, rant over.

2

I’ve had similar issues with Cordova complexity. It’s great that it works so effortlessly out of the gate, but as soon as a few cordova packages are added, things get difficult (for example, just configuring a Facebook plugin is madenly difficult to figure out, because you can’t access the Cordova build command in any obvious way). Part of the problem is that the system is sort of cloaked - it’s hard to tell where Meteor ends and Cordova begins.

I wonder whether it would make sense to divorce the two - would it be easier to start with Cordova itself and build that way? This is how Meteor currently works with React Native - they are not integrated. With RN, you just build a RN project, and then integrate Meteor inside there. Would it be easier to build with Cordova that way too?

3

I think you need to decide if Cordova is in fact the right solution for your mobile app. If you need true native performance or the primary interface for your app is going to be mobile, I think you are better off building your mobile app either with native tools or React Native, and not Cordova.

We have a 50k SLOC B2B SaaS app running with our primary interface via a web browser, but we offer iOS and Android apps built with Cordova for our customers as well. We do use a number of Cordova plugins besides those used in Meteor packages (cordova-plugin-whitelist, cordova-plugin-wkwebview-engine, cordova-plugin-meteor-webapp, cordova-plugin-statusbar, and cordova-plugin-splashscreen) in our app:

cordova-plugin-appavailability@0.4.2
cordova-plugin-calendar@4.6.0
cordova-plugin-customurlscheme@4.3.0
cordova-plugin-device@1.1.7
cordova-plugin-email-composer@0.8.11
cordova-sms-plugin@0.1.11
uk.co.workingedge.phonegap.plugin.launchnavigator@4.0.7

My recommendation is to use the most minimal set of Cordova Plugins to implement your app’s feature requirements.

With that said, I don’t think managing dependencies between Cordova Plugins is any more complex or difficult than managing dependencies between any packages or package managers such as NPM or Meteor packages. There is a Plugin.xml config file for each Cordova Plugin just like there is a package.json and package.js config file for NPM and Meteor packages where you can see any dependencies on other Cordova Plugins.

Also, as of cordova@6.1.0 plugin dependencies can also be specified in a package.json file.

Meteor tries to minimize Cordova Plugin compatibility issue between Meteor versions by “pinning” the compatible versions of Cordova’s core plugins with the versions of cordova-ios and cordova-android Meteor is using to build the mobile apps. You can see these dependencies in meteor/tools/cordova/project.js. There was a “bug” when we updated to cordova-ios@4.5.0 as we should have also updated to cordova-plugin-console@1.1.0 as this would have prevented this and this.

In addition, you can always override which version of a Cordova Plugin Meteor will build your app with by manually installing a specific version of the plugin in your ./meteor/cordova-plugins.

Edit: I’d also like to see Cordova releases decoupled from Meteor versions sometime in the future as per this feature request.

2 Likes
4

Yes, I have to agree - it’s a nightmare.

I wish Cordova versions would be decoupled from Meteor’s release versions. Sometimes I got the feeling that Cordova was just upgraded to the latest available version - without performing any substantial tests.

This was one of the main reason why I kept my app on 1.2 for a long time. Now, I eventually was able to upgrade it to 1.6, but this took me a looong way.

3 Likes
5

Thanks so much for the considered response and the insight to your implementation, a lot of useful information here, and all in one place too.

I’ve some work to do.