If you are a software developer, then you probably already know, that one of your many roles is definitely not to be yet another wheel inventor. At least, not in most of the cases.
I would like to write about JavaScript dependencies. But let's start from the beginning. If you are a software developer, then you probably already know, that one of your many roles is definitely not to be yet another wheel inventor. At least, not in most of the cases. World has proceeded far enough to say that today there exist packages for almost everything, making our development easier and more efficient.
This of course is not an encouragement for losing interest in other issues - every package has quite a large space to improve and evolve. However, your business goal is to bring a complete product on a plate just on time or even before it is up. Packages will help you fulfill those plans, bringing npm or yarn on the top of your best friends’ list, but be aware: any solution, as well as this one, may also bring risk. And we will try to describe it and show you a better way of getting away with it in the article below.
Imagine a large JavaScript project. Business requirement obligates developers to use a specific package, allowing a proper integration with another system of a client. And that is completely fine. MVP has been brought on time, next contract has been signed and development is carried on. Client asks to integrate the next part of a system, which requires your package update.
This part goes well, until tests are fired. It seems that the package contains a simple, but inconvenient bug, that has not yet been fixed in any product release and it is known that this won’t happen soon enough. You cannot just fix your node_modules directory - it should be removed out from your repository from tracking, therefore your collaborators will never know anything about your changes! Well, while you were reading this, probably you have already understood what to do - fork. But do you really need such a hammer?
You must be aware, if the problem you are facing with is going to involve just you or a larger community. Sometimes, people interpret lack of certain functionality as a bug, which is not always correct. Therefore, your solution may not be accepted by a community and not included into an official repository. However, you still need it here and now. Well, let’s patch it!
According to the release notes of github repository, patch-package ) was released officially in May 2017. It is a powerful tool, that allows modifications inside dependency project to be installed in your node_modules directory. Some may say that this is quite a madness - firing install command your dependence manager will overwrite the changes.
Well, this is correct. However, a patch-package coexists with npm and yarn perfectly (I must admit it works slightly better with npm so far, you can read more in “Why you should use postinstall-prepare with Yarn?” section of README file) and takes full advantage of a script preparation (“script”: { “prepare”:“”}) of your package.json file. Patch-package literally creates a diff directory between your changes and the original package, stored in the patch folder of your actual project.
After running install command and downloading all dependencies, it applies that difference to the project directory, making a perfect reconstruction of your changes for all collaborators. It makes your life simpler, doesn’t it? The solution has some disadvantages as well. The patch-package cannot fix dependencies of your package or make any changes in package.json.
In this case you may use the fork solution. Also, you must consider the number of changes you are about to apply into your dependency package and whether they will grow in time. In case the will - you should think carefully when using fork, as this is a project of your own.
Patching is a great way to fix your dependencies without creating endless forks and generating multiple project sources. But you should always remember, that taking advantage of community should not be a one-directional. If you find a bug or feel like you can improve the package you’re using, you should always consider helping others by registering an issue or even by contributing to the project!
