I am not sure how I got into this situation, but somehow the plugins and their corresponding ionic-native modules got into an inconsistent state. In retrospect i think I did a bad job merging config.xml and package.json after merging my master branch into a feature branch that I hadn’t touched in a long time as I am finally getting back to working on that feature.
I had to go through the laborious process of removing each plugin one at a time, re-compile and re-run my app on the device until deviceready would fire again. To try to isolate which one might be the problem I had to add them, compiling and running in between each one. I finally got to the point where deviceready would be called with all of my previous plugins installed (newer versions now).
My application still wasn’t working very well… SQLLite databases wouldn’t open properly, log messages were missing, etc. I just realized that this was due to inconsistent versions of my ionic-native libraries. I haven’t tested everything yet and there are still one or two things that are not working.
There isn’t really a question here, more of a rant that there has to be a better way to detect this situation and get better logging out of the system. If anyone has any ideas, I am all ears.
I guess that’s one of the thing Capacitor try to improve, one tool which provide all the features and wrapper. Furthermore, the fact that with Capacitor, if I understand correctly, you only create your platform once and therefor probably save it into Git too, will make the app more traceable
But beside that, I’ve to say, I do time to time face problems of incompatibility between plugins, can’t deny, but incompatibility between the ionic-native wrapper and its plugin, honestly, I never faced that situation or maybe only once when I was testing an alpha version of v5 back in January this year
“Best” solution in such a situation is often “just” to update them all to the most recent release and fix your code that goes with it. Also takes some time, like what you did, but after that your app will be in the best state possible concerning plugins.
I appreciate your feedback both of your feedback. Like I said part of it was just a rant because I lost 6+ hours of productivity on a project that I only have time for on nights and weekends. This is more on the Cordova side than the Ionic side, but I wish there was more transparency into the native plugin loading progress so you can know which one failed when deviceready isn’t called.
Is there perhaps some low level Cordova log or verbose mode that would have told me this?
On the Ionic side when you have a difference in version between the Cordova Plugin and the Ionic wrapper things can just fail silently so in that respect it is hard to know what is going on. In my specific case the SqlLite open call was returning the database before it was really open, which was causing the “new transaction waiting on open database” error. I am not sure what to do about these types of issues.
Always updating everything all the time is a good general principle, however I’ve run into cases where that isn’t always feasible because feature XYZ is broken in a package and you need to stay on an old version until it is fixed (angularfire and local notifications come to mind). I guess caveat is update all the time, but document well the exceptions so you can be careful around them.
That could possibly be solved in Ionic Native by checking the version of the installed native plugin - although I am not sure if that is exposed during runtime and not only via package.json etc. Problem: Someone had to document and code some compatibility table into Ionic Native… which would be prone to errors ./
This may be naive of me, but rather than maintaining a table of all Ionic Native libraries to Cordova plugins in ionic native, just have the ionic native library list the Cordova plugin as a dependency. Then you have a command in the cli which adds both the Ionic Native package and does the Cordova plugin part as 1 command.
What would be the difference here? You still have to define exactly which version of the plugin the Ionic Native wrapper applies to. Because if you just install the newest version, it might have stuff that is not supported by the Ionic Native wrapper yet. If you pin it to a version, bugfixes of the Cordova plugin will not get applied without an update of the Ionic Native wrapper.
Besides that, Ionic Native wrappers are installed via npm install, I am not even sure if you can bundle that with an installation via cordova plugin add .... Unless you ditch that and have a Ionic CLI command for installing Ionic Native wrappers - which would be another piece of software to maintain 
I totally see your pain and everything, but there is no simple solution.
I didn’t really think it through too hard… it would be nice if there was some kind of way to know whether or not you were in an inconsistent state at build time.
What really annoys me is that in trying to get back to a working state I just checked out a clean build of my master branch, which was working successfully as recent as August 3rd. When I build and run that version the same issue where deviceready is never called is the result. I checked in the package-lock.json file which I thought would potentially protect me from version changes but it probably does not.