Different node package versions in different branches of app in package.json?

Question

The scenario: We have several similar but customized Node applications, all of which include our own common library/package which we include as a dependency in package.json, all on BitBucket, all under development.

Each application has 3 branches, 'develop', 'staging', 'production'

The library also has 3 branches, 'develop', 'staging' & 'production'

We want to use the 'develop' branch of the lib for develop version of our apps, same for staging & production.

We can do that in package.json with:

ourapp dev branch package.json

"dependencies": {
    "ourlib": "git+https://[email protected]/our-org/ourlib#develop",
    "ts-jest": "^27.1.2",
    ...etc.
}

ourapp staging branch package.json:

"dependencies": {
    "ourlib": "git+https://[email protected]/our-org/ourlib#staging",
    "ts-jest": "^27.1.2",
    ...etc.
}

The issue/concern is promoting/merging from dev->staging->prod - to make it foolproof. When we are satisfied with ourapp dev branch, we merge it into staging & deploy.

But of course then after the merge, the ourapp staging package.json will then get over-written with the dev package.json:

"dependencies": {
    "ourlib": "git+https://[email protected]/our-org/ourlib#develop",
    "ts-jest": "^27.1.2",
    ...etc.
}

...instead of the staging branch of ourlib - one solution could be to edit the staging ourapp package.json immediately after the merge to restore the staging branch for the lib - but that's way too clumsy and error prone.

I would imagine this must be a common scenario, but none of us have that level of NPM expertise.

I'm wondering if there is any way to do it with environment variables in .npmrc or somewhere, or anything else - so something like:

"dependencies": {
    "ourlib": "git+https://[email protected]/our-org/ourlib#$NODE_ENV"
    or
    "ourlib": "git+https://[email protected]/our-org/ourlib#${$npm_package_env}"
    or???
}

Or is there any way to include another package.json within the main - which would be in .gitignore, like:

{
  "include" : "env.package.json",
  ...
}

• Or is there some other, obvious solution/approach/technique I'm missing?

Thanks for any tips...

Answer 1

I finally figured out how to do what I wanted to do - install different versions of a library in different branches of an application, without over-writing the branch specific versions when merging (thanks to assembling several different threads - thanks to all!).

It's a combination of .git & npm / package.json -

In package.json, under dependencies, instead of the library or package or repo, use a file dependency:

"versionlib": "file:./versionlib",

Create the subdirectory ./versionlib , and in there create a package.json with the particular branch/version of the library you want installed in your application branch:

{
  "name": "develop-lib-branch",
  "version": "0.0.0",
  "description": "Installs the develop branch of Library",
  "dependencies": {
    "mylibrary": "git+https://<credentials>@bitbucket.org/<repo>/mylibrary.git#develop"
    }
}

GIT: First, configure git (locally or globally) to enable a merge driver:

git config merge.ours.driver true

Then create a .gitattributes file with:

mylibrary/package.json merge=ours

Create the mylibrary/package.json for each of the branches of your app that you want to load different library versions -- in production,

{
  "name": "prod-lib-branch",
  "version": "0.0.0",
  "description": "Installs the prod branch of Library",
  "dependencies": {
    "mylibrary": "git+https://<credentials>@bitbucket.org/<repo>/mylibrary.git#prod"
    }
}

Then you can merge your app's develop branch to prod branch, but still install the prod branch of the library when you npm install on prod.

And then when you are ready, you can merge the develop branch of your library to the prod branch of the library, and when you install your app on prod, you will install the prod branch of the library, not the develop.

I have no idea why I keep coming up with use-cases/questions that seem very obvious/important to me, but apparently of interest to almost no-one else - but just in case anyone else is searching for a similar solution, I thought I would share mine.