Perhaps, you are developing your own frontend library, which is shared across multiple production working applications.
It is great, because core codebase is DRY, you can put more time and effort into fixing bugs and problems once, for multiple applications.
But let’s say your team develops the tool, so breaking changes occur or a visual change is applied to some of your components. What then? How to find a certain point in codebase, where a hotfix should be applied?
The problem
It’s easy to imagine a scenerio, where a hotfix is required for certain bug in a library, which was installed in certain version relatively long time ago. In a mean time library itself has been developed and since dependency lifecycle in JS world is very short, you might fall into trap of enforced dependency updates.
Enforced update means you have to apply the hotfix on top of current version of a library, which is far in front of production application
Possible solutions
- You could simply apply the patch, bump library version, upgrade every breaking change in production app and ship it. This is enforced update path.
- You could also tag production version of library both in the repo and npm registry, to easily find historical version and fix it there. This solution is much more flexible, because now you have options and can decide to upgrade. It’s not forced upon you.
The solution
Git repository
When your application is production ready, you should tag your application, but also tag your npm package with library. Let’s focus on library source code.
First of all, I advise creating a separate protected branch for production library code with certain human-readable name. You could also git tag here.
git checkout -b production
git tag -a v1.3.0 -m "production"
Of course both branch and tag names should be more descriptive.
NPM registry
Next, utilize npm dist-tags to mark your library package version with similar (or even the same) name, which suggest certain project. This will allow you to easily install and track production used package.
To publish current version with a dist-tag run:
npm publish --tag production
To apply a dist-tag to an existing package version run:
npm dist-tag add my-library@1.2.1 production
Then with time come back to certain source code, push hot fixes, or merge with main branch if needed and update the dist-tag version accordingly.