CODEWITHSUNDEEP
node.jsgitnpmversion-controlgit-flow
Tirtha
Tirtha

Reputation: 872

Versioning of npm dependencies with standard gitflow

I am following standard gitflow, and I have different environments for testing the dev builds, and release builds. master goes to production.

I also have my JS app divided into multiple private npm modules which goes into private npm repository.

Q1

Is there any way I can version my npm packages, against the branches they are built on in a standard way?

What I have tried is, I have prerelease pre-ids added to the versions. like
1.0.0-rc.0 //for master
1.0.0-beta.0 //for release
1.0.0-alpha.0 //for dev

But if I create a feature branch from master, it contains the master's version. When I try to raise a PR from it to dev, then it shows conflict, since dev has -alpha.x in its version. To resolve the conflict, I'll have to consume the target branch's versioning. Same issue when it goes for merging on release branch too.

And when it comes to merging to master, the release version (one with -beta.0) completely replaces the master. So it becomes like this: on master, 

| It was        | After Merge   | After version bump  |
| ------------- |:-------------:| -------------------:|
| 1.0.0-rc.0    | 1.0.0-beta.0  | 1.0.0-rc.0          |

Ideally after the version bump i would have wanted it to be 1.0.0-rc.1

Is it possible to keep package JSONs out of versioning.

Q2

How do I control the versioning in the package JSON of the application where these NPM modules are consumed? It too is on gitflow and feature branching model, and I would want that the App, when it is building on dev branch, it builds with artifacts that are published from their respective dev branches.

Honestly, I might be misusing gitflow too, but as of now, too confused to figure out where I'm going wrong.

Any Help will be appreciated.

Thanks in Advance

Upvotes: 3

Views: 2208

Answers (2)

Tirtha
Tirtha

Reputation: 872

The way I solved it is, //${buildNumber} and ${branch} are available as env variables in the build agent(at least available in jenkins/bamboo) tagversion="1.0.0-${branch}.${buildNumber}" echo $tagversion npm version $tagversion

so my builds are created and published as 1.0.0-master.1 //for master 1.0.0-release.1 //for release 1.0.0-dev.1 //for dev

Upvotes: 2

Marina Liu
Marina Liu

Reputation: 38106

You can user merge strategy as ours for package.json file in all branches. Details steps as below:

  1. Configure merge.ours.driver as true

    git config --global merge.ours.driver true

  2. Add .gitattributes file on each branch

    Add .gitattributes file with below content on each branch as below:

    echo 'package.json merge=ours' >> .gitattributes

    More details, you can refer last part (Merge Strategies) in Git Attributes.

Until now, for most situations, package.json file won't be overwritten during merge.

Note: pakage.json file will be overwritten for recursive merge. When merging changes from branch1 to branch2, if the file package.json is only changed on branch1, the merge commit will keep the package.json file with the version from branch1 by recursive merge strategy.

Such as on master branch, the version 1.0.0-rc.0 has not changed; while on release branch, the version has changes to 1.0.0-beta.0. When merging changes from release branch into master branch, the version will be 1.0.0-beta.0 (as you mentioned).

So for recursive merge situation, you need to manually change the package.json file version after merging:

# On the merged branch, as master in above example
git checkout head~ -- package.json
git commit -m 'use the original package.json after recursive merge'

Upvotes: 1

Related Questions