How I Dealt with a Bug in an Abandoned Library

Marco Fiset — Fri, 14 Jun 2019 02:10:57 +0000

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!

You Should Learn a New Programming Language

Marco Fiset — Fri, 07 Jun 2019 19:29:15 +0000

I'm comfortable writing C#, PHP and Javascript. Those are the languages I use professionally. While I don't consider myself an expert in any of them, I can at least say that I'm fairly proficient with them. I don't need to deliberately practice my skills at those languages anymore because I know them very well. What I will do from time to time is learn and experiment with new libraries, integrating them into my projets if they solve a problem I have.

Once you master a language, only learning new libraries will not be enough for you to advance your skills further. Sure, some library might come along and challenge the status quo, but generally you will tend to stick with the patterns you're comfortable with. You get your job done just by going through the motions, without thinking much about what you're doing.

That's where you stagnate. The last thing you want to do is fall into complacency.

Past a certain point, if you really want to push your skills further, you need to do something different. No just do "more of the same". Learning a new framework or a language that's very similar to one you already know is just a new way to do the exact same thing. It's easy to learn Java or Python when you already know C# or Javascript. You will feel right at home after a couple weeks.

You want to learn a language that will make you feel dumb at first. You need to be disoriented in order to grow as a developer. This is where you'll push the boundaries of your knowledge into new territories.

My personal suggestion would be Clojure. And that's a story for another article ;)

What would be your suggestion for a programming language that goes off the beaten paths?

DEV Community: Marco Fiset

How I Dealt with a Bug in an Abandoned Library

Time to Hit the Fork Button

You Should Learn a New Programming Language