Development: Don’t hack the libraries you use

These days, it’s all about rapid prototyping, continuous integration and “moving fast and breaking things”. There’s no point in implementing a time and date Javascript library, as moment.js already does that job wonderfully.

The catch here is that you should never ever update a library you use, unless you’re 100% confident that you’re never going to need to upgrade it. Ever!

I’ve seen this over and over again. “We need that library, but instead of X it needs to do Y.” This is a temptation that might easily lead you on a path you’ll most likely regret.

First, it is possible that other libraries depend on the one that you are intending to change. This means that, at some point, you’ll not be able to upgrade those libraries, since they’ll ask for a newer version of the one you’ve just hacked, and you won’t be able to upgrade the one you’ve hacked because… well… because it is not what it used to be, and the new version is unlikely to do what the original one did. And so, my dear friend, I have to sadly break it to you: you’re screwed.

Now, to keep from getting you screwed, here are a handful of don’ts…

Wordpress

Don’t hack the Wordpress code! Use plugins to extend its core functionality. That’s what plugins are for. That’s why they added hooks and filters everywhere, so that any kind of feature or function can be extended with your own requirements without hacking into the Wordpress core.

And don’t hack Wordpress plugins, unless you’re the one who developed them in the first place. As with Wordpress, you will never be able to upgrade them again without losing all their custom functionality.

Don’t hack any npm package! You’ll quickly find out not only that you won’t be able to upgrade them, but you won’t even be able to deploy the hacked package, because both CI and your deployment code downloads the original npm package instead of your hacked one. Not to mention that you probably won’t be able to commit your hacked library into CVS, because node_modules should not be tracked by the CVS.

Don’t hack packagist packages. Composer is meant to keep your codebase light, and to import whatever libraries you need. It is the PHP counterpart to npm packages. It’s almost always a bad idea to hack a package installed by composer.

Fortunately, lately, most frameworks are installed via npm, composer or other package management systems, but just to make sure, here it goes: don’t hack frameworks of any kind!

As a general rule, don’t hack any code that your team hasn’t written, or that isn’t your responsibility to maintain.

Know the rules, and then break them!

Now, considering that we know the rule, when do we break it?

There are moments in time when you need a small component that doesn’t do what you want it to do, but it does 90% of what you want it to do. This is a moment when you can, and maybe should break the rules above. But do it smart!

First, take a moment to read the package’s license. Make sure you are allowed to copy and alter it. This is important, no matter if you’re working on a personal or company project. Stealing another person’s Intellectual Property is never a good idea and will lead you on a path of no return once infringement claims start to pile up and attorneys start looking for you. And even if this doesn’t happen, you still don’t want to be the one who stained the open-source principles and community.

Second, copy the component, library or package out of node_modules / vendor or whatever package storage folder you have, into your code folder. If you can, change its namespace so that it won’t come into conflict with the original one if you later decide to use them both.

Third, remove the original dependency from your project, if other components, libraries or packages aren’t relying on it.

Now you have the component’s code included in yours, so feel free to update it so as to suits your needs, provided that its license allows you to do that. In most cases, you’ll be able to do whatever changes you need as long as you keep the original documentation, including the author and the license, together with the modified code. Any coder that comes in contact with that component will see that it was originally developed and published by X, which is, in most cases, exactly what the author wanted: to get the proper credits for his work. After all, most libraries out there have been implemented out of necessity and good will, not incentivized by money or other form of payment.

Therefore, it’s not only good practice not to hack the libraries you use, but also a wise decision. In the same way, it’s not a wise idea to hack your microwave, your TV or your car.

So, have fun coding!