What parts of cordova cli generated projects can be safely versioned in source control?

It depends on you project and your workflow.

For a lot of projects, the ./www folder would be sufficient as already mentioned, however there are some other folders that could be good to have depending on what aspects of the cli you are using.

Examples:

  • ./merges for platform specific HTML/CSS/JS overrides
  • ./.cordova for cli hooks (like before_build, after_plugin_add, etc)

Plus anything else custom you might want to keep out of ./www during development. For example, I have a ./src folder and the contents are concatenated and added to ./www as part of our build process. Our unit tests are also outside of ./www.

Instead of including a specific folder, I have a .gitignore that keeps build artefacts like ./platforms/* and ./plugins/* out of version control.


2015 - Cordova 5.1.1 answer

After working for some time with a Cordova project from 3.4.0 to 5.1.1, here's my feedback!

My .gitignore file looks like:

*~
**~
platforms/**
plugins/**

The www / .cordova and other folders you need are versionned.

My .cordova folder is currently empty (I used to have some errors when no .cordova folder, maybe it's not the case anymore)

All the plugins and platforms should be registered into the config.xml file.

If you add plugins by command line, use cordova plugin add $pluginName --save --shrinkwrap -> it will add the plugin automatically to config.xml and fix the version number, making the Cordova project easier to share among developers.

Read more about it and about sharing cordova projects, by the feature author.

Having the plugins in config.xml permits the plugins to be installed on other developer computers when they install a platform. Without that they will need to add themselves the plugin.

Somehow the config.xml acts like a package.json for NPM projects. But I still don't know how to handle a new plugin added, as far as I know the plugins are only installed during platform installation, there's no npm insall/update equivalent (but you can uninstall/reinstall the platform).

Here's an example config.xml from my project:

<?xml version='1.0' encoding='utf-8'?>
<widget id="co.xxx" version="0.2.6" xmlns="http://www.w3.org/ns/widgets" xmlns:android="http://schemas.android.com/apk/res/android" xmlns:cdv="http://cordova.apache.org/ns/1.0" xmlns:gap="http://phonegap.com/ns/1.0">
    <name>xxx</name>
    <description>
        Your Knowledge Network
    </description>
    <author email="[email protected]" href="https://xxx.co">
        xxx
    </author>
    <content src="index.html" />
    <preference name="permissions" value="none" />
    <preference name="StatusBarOverlaysWebView" value="false" />
    <preference name="android-minSdkVersion" value="14" />
    <preference name="android-targetSdkVersion" value="22" />
    <preference name="phonegap-version" value="cli-5.1.1" />
    <plugin name="cordova-plugin-device" spec="1.0.1" />
    <plugin name="cordova-plugin-console" spec="1.0.1" />
    <plugin name="cordova-plugin-whitelist" spec="1.1.0" />
    <plugin name="cordova-plugin-crosswalk-webview" spec="1.2.0" />
    <access origin="*" />
    <allow-intent href="*" />
    <engine name="browser" spec="^3.6.0" />
    <engine name="android" spec="^4.0.2" />
    <plugin name="cordova-plugin-statusbar" spec="^1.0.1" />
</widget>

The platforms do not get automatically installed (as far as I know), but at least when an user install the platform, he'll get the right platform version!

Some other people are using Plugman, a tool intended to manage Cordova plugins (not tested yet).