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

Question

I'm looking to use Cordova CLI instead of a home grown ant solution for command line management of a phonegap/cordova project. I'm wondering what parts of the directory tree, if any, should not be placed under version control?

Answer 1

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.

Answer 2

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="info@xxx.co" 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).

Answer 3

Well what u control is your own choise, although, I would personaly only use version-control on the www folder, since is where all your coding and stored content is ( html, css, js, images, audio, etc ), all the rest will be static content (in most of the cases)

Answer 4

Unfortunately I can't add only a comment, so here's my reply for @blockhead and Sebastien Lorber:

It is not necessary to save files from folder 'platform' even file 'AndroidManifest.xml' (or any configuration file for other platform). You can specify your preferences in 'config.xml' and it will affects these generated platform specific configuration files (e.g. AndroidManifest) - see phonegap documentation.

Then you can have under version control only folder 'www' and file 'config.xml'.

Answer 5

If anyone wants to code of Cordova CLI android platform centered (Android Hybrid complex project) into subversion then these files can be excluded while developing with team:

// to exclude files into repo
.gitignore
.gradle
.idea
local.properties
android.iml

/build
/gradlew
/gradlew.bat
/gradle

CordovaLib/CordovaLib.iml

If anyone is having problems with an svn error while import project of Gradle option from disk only not inbuilt subversion client of android studio then the following link will be helpful to you: https://stackoverflow.com/a/34633162/5287727

Answer 6

I have been a cordova dev since v2.9 and the typical advice of excluding the platform and plugin folders works most of the time.... except for when it doesn't.

I have noticed on a project that feels like it uses every plugin known to man that this mantra has broken down, and I am unable to easily go back and forth in version control and reliably produce a new build.

This is for a few reasons:

Apple changes things up, and as time goes along there are a number of cordova hacks that need to be added to a project to get it to be reliable. For example, iOS 10 added a requirement that if you use the camera, then you needed to specify what you were using it for - or the app would crash when you tried. While I was waiting for the camera plugin to fix this, I needed to edit the iOS source files, then some time later I needed to build an old version, and in crept the issues.

But the real pain is when plugins stray from the cordova way of doing things. This project I am referring to uses the Adobe Aviary / Image editing SDK. Their instructions are to install the plugin, copy over some sdk files downloaded separately, then install it again. I tried making a script that wouldn't kill it, but it has ended up just being that I now commit the plugins and platforms directory to the app - this way I can go back in time and reliably recreate a build.

Yes it adds more size to source control, yes I would love to do it "right", but it has bitten me hard. Just my $0.02

TL/DR - When you starting working with more than a couple of plugins, you might need to consider adding the platforms and plugins folder to source control

---

Update 2019-11-05

For the project I was referencing we have since made a commitment to just use things that integrate correctly, and now I believe it is better to not check platforms into source control at all. If the plugin doesn't work, the client should not be using it.

Cordova has also moved away from providing an upgrade path for platforms, instead requiring you to remove and add the platform again - this means that this workflow is the only way forward in my opinion.