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.
Time to Hit the Fork Button
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:
"some-library": "git+https://github.com/username/package.git#tag"
Where 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 (package-lock.json in 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!
Top comments (5)
No. Really no.
You just create another Linux distro to fix just small issue or new design concept adapt...
What you can is to create new package, incorporate all fixes to it, inform other and try contact owner showing that you can maintain library.
Start maintaining and creating better word.
While that is definitely the "ideal" situation, not everyone has the time/desire to become a package maintainer.
package maintaining can - probably is - time and effort consuming, but, a pull request would be really nice to help the owner and future users who might run into the same bug
I was once using a pretty commonly used library (C# though). And I had an error which was mindboggling me. I was able to push it, but I was not able to identify it nor could I eliminate it.
I had only a few years (2 or 3) of experience and never did something like what I had to do before. So, of course, I assumed, that the error must be in my code. And I spent about one week looking for it until I had no doubt at all, that it must have been in the library.
Fortunately it was still maintained, so it took them another week to find it and deliver the fix.
Yes we used a very uncommon edge case. So that’s why, nobody encountered it before and most likely nobody ever will.
I'm in a similar sitituation and really consindering a pull request to the lib
imo, it's something you - and everyone in such case - should really do, whether the lib is "abandoned" or not