DISCLAIMER: This is pretty much the first time I had to deal with such an issue. If you have any suggestions about how this should have been dealt with, feel free to share in the comments :)
There comes a time in every developer's career where one will discover a bug not in their own code, but in a library they're using. That happened to me quite a few times in the past, but it was the first time it occurred in these particular circumstances.
Most of the time, when I encounter a bug in a library, I find that it was ultimately fixed in some newer version of the lib. I update my package.json file,
npm install away and my bug is fixed. Sometimes it involves reading through the changelogs to identify any potential breaking change and it's usually a walk in the park.
This time however, was different.
The version I was using was 4 years old. There where 100+ issues on the Github repository, alongside 30+ Pull Requests that were yet to be merged. There was a new version in development, but the last commit was written 10 months ago. There was no chance in hell that my bug would be fixed anytime soon, let alone be merged if I decided to fix it myself.
I looked at the code, and since it's a library I was already familiar with, I knew exactly where to look.
I found the 2 offending lines of code (actually it was the exact same line in 2 different places of the same file), patched them, committed and then pushed to my own fork of the repo. Now, Github was right there, nagging me about my version of the branch which was one commit ahead of the source repository. For good cause, I will definitely take the time to write tests for my bug fix and submit a PR back to the author, even though I have no hope of it being merged anytime soon.
It was now time to used my patched-up lib in my project. Well, it turns out that
npm can download library straight from Github. All you gotta do is open up your
package.json file, and change the version number of the lib you want to replace with this:
username is your Github (or your organization's) name,
package being the repository name and
tag referencing either a particular commit's SHA-1 number or a tag.
Now you may think that you're just an
npm install away from your troubles going away, and you would be right! But don't get your hopes up just yet as you may encounter some problems 🙃
At this point, I was moving back and forth between my own version of the library and the actual published library to make sure that my changes were working as they should. The bug was still there. Oh no. Whatever I did, change my package.json file or deleted my node_modules directory and reinstalling, the wrong version of the library would get installed.
It turns out that
npm and pretty much every package manager out there uses some form of dependency version locking mechanism. It means that whenever you install a dependency, the exact version you installed will be logged into a file (
npm's case) which, if committed to your repository (you should definitely do so), will ensure that everyone on the team uses the exact same version of each package your project depends on.
What I needed to do in order to install my own version was to actually open the package-lock.json file and rip out the piece of JSON referencing that particular library. Now
npm install would correctly fetch from my Github repository.
And surprise! The bug was gone! I quickly transferred ownership of the repository to my organization and updated my package.json file accordingly. Here's to more buggy libraries and forked repositories in the future 🍻🤓
Feel free to discuss in the comments about some similar situations you might have found yourselves in! Any insights is greatly appreciated by me and anyone who enjoyed this article.
Hopefully this article was of some use to you 😇
If it was, please consider following me here and on Twitter for more of this type of content! I'm dedicated to sharing what I learn here, however trivial it may seem to the more advanced of you. Cheers!