Deprecate State #1324

The state architecture (herein "state") in the CLI contains some of the oldest untouched code in the CLI. Its sole purpose is to provide easy management of Cordova platforms and plugins in Ionic apps through the ionic state command.

The majority of the state code can be found here: https://github.com/driftyco/ionic-app-lib/blob/master/lib/state.js

In this issue I will explain why state is now unnecessary (perhaps even harmful) and why it does not fit in with the goals of the Ionic CLI. I welcome all input.

State keeps a manifest of Cordova plugins and platforms in package.json. When a plugin is added via ionic plugin add, it inserts a record into the cordovaPlugins property. Similarly when a platform is added via ionic platform add, it inserts a record into the cordovaPlatforms property.

Just so everyone is up to speed as I go forward, ionic plugin/platform commands also call the cordova plugin/platform commands under the hood, which actually add/remove the platforms and plugins. These Cordova commands have always been around. What hasn't always been around in Cordova is the ability to save and restore platforms and plugins to your project. When you committed a Cordova project to git, you would ignore the platforms and plugins directories, unless you want a massive amount of ever-changing files and dependencies in your repo.

Enter March, 2015. Cordova 4.3.0 is released with just such a feature. There now is a way in Cordova itself to manage platforms and plugins. See Platforms and Plugins Version Management. With a simple --save option appended to the cordova platform/plugin commands, the platform and plugin versions are all saved in config.xml. Upon running cordova prepare, Cordova checks local installations, compares it with the manifest in config.xml, and updates the local project accordingly.

August, 2016. We still have state in the Ionic CLI and we still have active users of the ionic platform/plugin commands. This means we have two ways of managing dependencies in Ionic apps. Vanilla Cordova apps have no such confusion. Every Cordova plugin in the world has cordova plugin add foo somewhere in their docs or readmes. When to use ionic platform/plugin vs cordova platform/plugin? Does cordova prepare (run with cordova build or cordova run) overwrite the ionic state restore command I just ran? What version of this plugin am I truly using?

I remember hearing about a developer who lost an Ionic project on their local computer. Fortunately, it was pushed up to Github. But, when they pulled it down, they could not get it to work because the plugins had all updated APIs. They had installed plugins with cordova plugin add as well as ionic plugin add, so their manifest was incomplete and/or just wrong.

Having two ways to manage Cordova platforms and plugins also creates confusion in other areas.

Ionic Package, which builds Ionic apps in the cloud, receives constant questions about why a plugin is missing. (why is my app a white box?) It attempts to cater to both plugin management schemes. It parses plugins from cordovaPlugins, which is an array of locator strings, or sometimes objects, or sometimes a lovely mix of both. Then it goes through and manually runs cordova plugin add for each one. Plugins defined in config.xml are just automatically added during the cordova prepare step. I imagine teams that are working on Ionic apps have similar issues.

Action plan: Let Cordova manage Cordova stuff. Deprecate ionic state command in CLI 2.0 and remove it in 3.0, with an informational message about using Cordova to manage platforms and plugins. Do not deprecate ionic platform/plugin commands--some do more than just modify package.json. Remove the state code that is run during those commands, however.

Thoughts? @mlynch @jthoms1 @adamdbradley @ericb @tlancina