Skip to content

Accessing more build information from your Cordova CLI hooks

Hooks now give you, as of cordova CLI 3.3.1-0.4.2, much more information about the environment you were executing in.

Before, if I had platform specific code, I needed to check at runtime:

App.config.flurryid = "";
    if (window.device && window.device.platform) {
        if (window.device.platform == "Android") {
            App.config.flurryid = /*REP*/ 'notreallyanandroidflurryid' /*REP*/ ;
        }
        if (window.device.platform == "iOS") {
            App.config.flurryid = /*REP*/ 'notreallyaniosflurryidxxx' /*REP*/ ;
        }
    }

Now, you can inject platform specific code at build time, via hooks. The runtime code is simplified to

App.config.flurryid = /*REP*/ 'myflurryid' /*REP*/;

and you just replace 'myflurryid' with the appropriate value from your configuration file (more on platform specific configuration files).

From the readme in the hooks directory:

All scripts are run from the project’s root directory and have the root directory passes as the first argument. All other options are passed to the script using environment variables:

* CORDOVA_VERSION – The version of the Cordova-CLI.
* CORDOVA_PLATFORMS – Comma separated list of platforms that the command applies to (e.g.: android, ios).
* CORDOVA_PLUGINS – Comma separated list of plugin IDs that the command applies to (e.g.: org.apache.cordova.file, org.apache.cordova.file-transfer)
* CORDOVA_HOOK – Path to the hook that is being executed.
* CORDOVA_CMDLINE – The exact command-line arguments passed to cordova (e.g.: cordova run ios –emulate)

Here’s a sample plugin which you can put in your hooks/before_prepare directory. If you do this and then run cordova -d prepare you can see the values for all the variables.

#!/usr/bin/env node

console.log("process.env.CORDOVA_VERSION: "+process.env.CORDOVA_VERSION);
console.log("process.env.CORDOVA_PLATFORMS: "+process.env.CORDOVA_PLATFORMS);
console.log("process.env.CORDOVA_PLUGINS: "+process.env.CORDOVA_PLUGINS);
console.log("process.env.CORDOVA_HOOK: "+process.env.CORDOVA_HOOK);
console.log("process.env.CORDOVA_CMDLINE: "+process.env.CORDOVA_CMDLINE);

Here’s the output for a test project.

Executing hook 

""/home/mooreds/git/testproject3/hooks/before_prepare/test.js" 

"/home/mooreds/git/testproject3""
process.env.CORDOVA_VERSION: 3.3.1-0.4.2
process.env.CORDOVA_PLATFORMS: android
process.env.CORDOVA_PLUGINS: 
process.env.CORDOVA_HOOK: /home/mooreds/git/testproject3/hooks/before_prepare/test.js
process.env.CORDOVA_CMDLINE: node /usr/local/bin/cordova -d prepare

Note that if you are using this for platform specific code, you will want to run the commands separately: cordova build android and cordova build ios. If you just run cordova build and you have both ios and android platforms installed, the process.env.CORDOVA_PLATFORMS variable will be android,ios, and your code won’t be able to differentiate between them.

If you want to know about more Cordova CLI changes, check out “3 Cordova CLI Changes You Should Know About” which covers version 3.3.1-0.3.1.

8 thoughts on “Accessing more build information from your Cordova CLI hooks

  1. Stéphane Péchard says:

    I was happy to find the README.md file and these information about the given environment variables. I have a problem with it though. As your script shows, the CORDOVA_PLUGINS variable is empty, even if I know I have some plugins installed (shown by ‘cordova plugins ls’). Do you know if it’s normal, or a bug?

    Thanks for the article.

  2. moore says:

    Hi,

    A few questions. What version of cordova are you running? Have you looked at the other variables–are they populated?

  3. Stéphane Péchard says:

    Here are what the other variables are for my sample:

    CORDOVA_VERSION: 3.4.0-0.1.0
    CORDOVA_PLATFORMS: android
    CORDOVA_PLUGINS:
    CORDOVA_HOOK: /tmp/Baz/hooks/after_prepare/1_env_plugins.js
    CORDOVA_CMDLINE: node /Users/stephane/Documents/produits/apache/cordova-3.4.0/cordova-cli/bin/cordova prepare –verbose

    I opened a dedicated issue with minimal steps to reproduce the bug: https://issues.apache.org/jira/browse/CB-6179

    Hope it helps.

    Thanks!

  4. Ross says:

    Thank you very much for this information.  I made a hook that helps to uglify a Cordova apps JavaScript/CSS when you run a prepare or build command.  I added it on GitHub here – https://github.com/rossmartin/cordova-uglify

    I’m open for any suggestions.

  5. moore says:

    Hi Ross,

    Thanks for the pointer. What percentage size decrease are you typically seeing, and does this hook make debugging harder? Does it make sense for this hook to only run on production and staging builds, so that dev builds have more sensible debugging line numbers, etc.

    See hook two listed here: http://devgirl.org/2013/11/12/three-hooks-your-cordovaphonegap-project-needs/

    Other than that, nice work, and thanks for sharing!

  6. Ross says:

    Hey Dan,

    Thanks for the quick response and feedback. I notice that “uglifying” my JavaScript files has cut their size by a little over half. My largest angular controller JavaScript file pre-uglify is 5.2 KB and after build it is now 2.4 KB in size using my uglify hook. Check out this post here on the Ionic forums about compressed code – http://forum.ionicframework.com/t/compressed-code-is-fast/2225

    “Uglifying/minifying” does make debugging more difficult. In my hook I show how you can make it only run when building for release, take a look at line 7 currently in my script – https://github.com/rossmartin/cordova-uglify/blob/master/after_prepare/uglify.js#l7

    I choose to uglify always partially because I want to make sure it doesn’t break anything and also to see how well it performs.

    One benefit to “uglifying” your scripts is that it makes it more difficult to reverse engineer. Many people know how easy it is to reverse engineer a Cordova application and “uglifying” your scripts is certainly better than leaving them untouched for a production app. Here is an excellent post about this dilemma – http://www.justbeck.com/three-ways-to-encrypt-phonegap-and-cordova-mobile-applications/

    My uglify hook doesn’t obfuscate your scripts nearly like the methods described in the post above but it is better than “letting it all hang out” like I have seen many production Cordova apps do :~)

  7. Ross says:

    I have just gotten bit by always “uglifying/minifying”. I’d like to change my stance on this now, lol. When I test using ripple I don’t uglify but I go back and forth when testing on the device. I’m kind of shocked that there is such a noticeable difference in performance on devices.

    Do you think concatenating all JavaScript files into one will be of benefit? I’m working on an Ionic app right now that has gotten fairly large and I’ve separated all my controllers into individual files. It might be best to create a process that combines all of them.

  8. moore says:

    Ross, I don’t know if concatenating all the javascript files will have a benefit–since it is a Cordova application, all assets are pulled from the filesystem, so there’s no benefit in turns of fewer network connections.  I guess you’ll have to run some benchmarks.  Please let us know what works.

Comments are closed.