Maintaining plugins and packages - best practice?

Does anyone have any best-practice advice (or links to such advice) on how best to manage an Ionic/Cordova project and it’s dependencies (plugins and packages) when switching repository branches?

For example. if I have version 1 of the Push Plugin in a development branch of my project and in an upgrade branch I have version 2 of that plugin (with perhaps additional dependencies that relate to it) what’s the correct process of switching between branches (and always being 100% sure everything is the same as the last time you were in that branch?).

I had real problems today doing something along these lines and ended up having to remove both iOS and Android platforms, manually removing a plugin, adding a different one, running npm install etc.

What’s the best way of handling this and not messing things up?


I was facing the same problem and finally solved it working like following:

  • Minor change: I switch between theses branches in the same project (“local folder”) as you do

  • Major change: I create and then clone the branch in a separate project locally and therefore work in another workspace

    git clone -b my-branch-name https://repo/project.git my-local-project-name

For example on my hard drive I would have:


where “my-project” would use push-plugin v1 and “my-project-branch-with-the-major-chg” would use v2

1 Like

Thanks. I’d not thought of that approach! Would be very interested to hear other opinions / advice.

1 Like

@reedrichards in the example you gave me, and you were working on changes concurrently in both projects, what would you process be for merging the two together (assuming you had to merge changes at a certain point) ?

@richardshergold of course I always merge at some point, I always deliver :wink:

first of all, I’m a one-man band. I just wanted to clear that up. Still I think my flow would be the same for a team but it’s good to notice it

Actually I work like the following:

  • master branch: I always build/deliver the final product from there
  • dev branch: on one side the day to day branch but also the staging one
  • other branches: like I explained above, complicated stuffs

during the development what I have to do is, time to time merge dev->special branch in order to keep synchronized and avoiding weird conflict (since I’m working in both branches)

then when I’m ready to go, I merge special branch->dev, staging, tests etc. and then merge into dev->master for the final run

does that answer your question?

1 Like

Yes, I think so. What I was getting at was what is involved in merging code in the two projects that you mentioned in your first reply, rather than merging branches within the same project (which of course I do all the time!).

1 Like

I think he was referring to having the project cloned to a different folder, not a whole new project in your scm, so you’d merge the different branches like you normally would then delete the second folder/clone.

1 Like

I try to summarize, just in case

In Git I could have branches like:


and then locally I would manage that with two workspaces

/User/me/workspace1/: master/dev/branch1_easy (I switch from one branch to the other)
/User/me/workspace2/: branch2_complicated

1 Like

thanks - I may try this out. And just to confirm - you can merge changes between master and branch2_complicted just like you would normally merge branches (even though the branches are in different workspaces) - and all git commit history etc is preserved correctly? (thanks for the advice!)

Probably but to be 100% that the branch is mergeable as a best practice I do: once finished, always merge firstly the branch in the source branch I used to create the branch

so let’s say I create branch3_something from dev, then before I merge into master I merge it firstly into dev and then dev into master

if I would have created branch3_something from master then I would merge it directly into master

Not sure that’s the correct way or something, but at least doing so I never face problems

1 Like

We wanted full trackability and reproducibility for all old builds, and at least sometimes github, or npm, or even internet may go down. Or repos or packages might dissappear after a few years.

And we wanted to not have to run cordova add/remove/prepare commands very often, like when switching branches or setting up a new development computer.

Our solution is to create multiple git repositories for node_modules, plugins, platforms folders and add them as git submodule in main project repo.

This gives us 100% reproducibility of older builds, and we don’t need to run any cordova add/remove commands to switch branches. Mostly we can just pull changes and build even when a new developer joins team. And as an additional benifit if some bug shows up after updating a plugin etc, we can see in git history what had changed in that plugin/platform’s code between the version that worked earlier and the version thats not working.

You can even just commit everything in your main repo if your project size is small. Our projects use some plugins with 100+ MB binary files, so keeping separate submodule repos helps keep main repo size small.

1 Like

Thanks @schngrg I quite like the sound of that. I’m not a git expert by any means though (I use Git Tower which helps me a lot!). So when you say, “create multiple git repositories for node_modules, plugins, platforms folders” what exactly do you mean in terms of the required steps? At the moment our Ionic project ignores these folders (as you would expect). I think you are saying we would leave them ignored in the project repo but create completely separate repositories for them? How would I create those repos? And once created I think you are saying they would be linked to the main repo by way of a sub-module? I’ve not used submodules before. Thanks for reading and commenting.

You are understanding it correct.

  • Create multiple repos, just like you created your main repo.
  • Remove the .gitignore entries for these folders.
  • Add the new repos as submodules to main repo (you will need to read up more on git submodules).
  • And thats it.

Option2: If all this sounds complicated due to multiple repos and submodules, and your project is less than a few hundred MB in size, just skip the submodules. Remove the .gitignore entries and commit everything within your main repo. Git operations will be a slightly slower if you are not on a SSD due to extremely large number of very small files in node_modules etc, but its not really a problem.

1 Like

Thanks @schngrg it’s actually the first step I am having difficulty understanding! If I already have a repo for Project A (which has node_modules ignored) how do I then create a new repository just for the node_modules folder within Project A? In Git Tower if I select Create New Local Repository and then select the node_modules folder inside Project A it errors saying “The selected path already belongs to an existing Git Repository at /path/ProjectA” - I think I must be misunderstanding exactly what you mean? (apologies for that and thanks again for offering advice)

Create a new node_modules repo in a new folder,
Move the node_modules content from your project’s folder into the new repo, commit and push.
Remove node_modules folder from project, add the new node_modules repo as a submodule.
Delete the folder where you created the initial node_modules repo outside the project.

1 Like

thanks @schngrg I may well give that approach a try too :grinning: