Before we continue, this article assumes that you have proficient knowledge in source version control software. This article will be using Git in examples.
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:
First, we have a
node_modules folder, and as with any node project, that can be ignored in your version control system.
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 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.
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.
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.
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.
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
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.
Then instead of using a global install, you can prefix all commands with
npx like so:
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:
- Clone your application repository
npx cordova platform add <platform>. Repeat for each platform the team member will develop for.
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.