Developing an Cordova App as a Team

Knowledge Prerequisites

Before we continue, this article assumes that you have proficient knowledge in source version control software. This article will be using Git in examples.

Developing an Cordova App as a Team

Solo development has it's benefits, but sometimes a job calls for more than one developer working on the application.

Every developer has a unique environment, some developers may be using Windows, others may be using Mac OS, and some may be using Linux. Even if you're entire team is using a consistent operating system, they still may be differences of installed software.

So how do you make sure that every developer is on the same page? First, a project should be managed by a source code version software, such as Git. But which files/folders are save to include and which files should be ignored. Well let's take a peek at the base cordova structure. After installing a platform and some plugins, you'll have a directory structure as follows:

$ ls
config.xml    package.json       platforms  www
node_modules  package-lock.json  plugins

First, we have a node_modules folder, and as with any node project, that can be ignored in your version control system. package.json and package-lock.json, like any node project, should be tracked by your version control system.

The remaining files and folders are cordova specific:

• config.xml - The file containing metadata and app configurations. This should be tracked by your version control.
• www - The directory containing the web assets for your cordova application. In simple configurations, this ca be tracked by your version control system. In more complicated setups, it can however sometimes be desirable to ignore the folder. We will talk about this in more detail later.
• plugins - The directory containing downloaded plugins. This acts as a cache and should be ignored in your version control software.
• platforms - This directory contains the native projects. This folder is generated and managed by cordova tooling so it can also be ignored in your version control software.

Therefore the final .gitignore file may look something like:

node_modules
plugins
platforms

The Rationale

Node modules can sometimes contains native binaries that are compiled specifically for your system. Therefore if you simply copy the node_modules folder from one computer to another, things may not work properly.

The plugins folder acts as a download cache. It's mostly remnants of the older system before Cordova used NPM. Nonetheless, there is no reason for this folder to be tracked by your version control system. It's also safe to delete this directory, if you want to make sure plugins are installed from scratch.

The platforms directory contains the native projects for each platform. It has many generated files that change on each build. General rule of thumb is you don't want generated files to be tracked by your version control system. It will save you from a headache dealing with complex merge conflicts.

Ignoring the platforms directory will also make it easier for someone to contribute to your app without requiring the SDKs for each platform. For example, a team member with windows can install just the android platform, but not the iOS platform and still contribute to development. Whle another team member with Mac OS can install the iOS development to test iOS and still make contributions to the same project.

The www directory is a bit special. Depending on your development environment, this can be ignored. If the application's web assets is entirely generated by your build system, then it's perfectly fine to ignore the www directory in your version control system. Sometimes you may have a mixture of files. For example, in my applications I have a tracked index.html file, but my javascript files are generated via Webpack so I have specific files that are ignored. General rule of thumb applies here, generated files should be ignored by your version control system.

Ensuring consistent cordova tooling

So far, we just talked about the directory structures and which files should be tracked or not tracked by version control systems. However having multiple team members using different Cordova versions can also be problematic. Personally the easiest way around this is to install Cordova as a dev dependency to your project.

$ npm install cordova --save-dev

Then instead of using a global install, you can prefix all commands with npx like so:

$ npx cordova platform add android

Other team members just has to run npm install to ensure that their dependencies are in sync with the project. This also has a benefit of your Cordova tooling to be tracked by version control.

New team members wanting to setup their environment will just have a few steps:

1. Clone your application repository
2. Run npm install
3. Run npx cordova platform add <platform>. Repeat for each platform the team member will develop for.
4. Run npx cordova run <platform> to run the project on their device or emulator.

Of course, the team member should also have the platform SDK installed first. Read the Cordova Docs to learn how to setup the platform SDKs.

That's it! Now your team should be able to collaberate efficiently on the same cordova project.