Go to content
The Codest
  • About Us
  • Services
  • Our Team
  • Case studies
    • Blog
    • Meetups
    • Webinars
    • Resources
Careers Get in touch
  • About Us
  • Services
  • Our Team
  • Case studies
    • Blog
    • Meetups
    • Webinars
    • Resources
Careers Get in touch
2018-12-27
The CodestSoftware DevelopmentTechnology NewsStartups

First aid for broken JavaScript dependencies

Daniel Grek

First aid for broken JavaScript dependencies - Image

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.

Let’s start with a story…

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?

Understand your problem

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.

Don’t be selfish!

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!

Related articles

The Codest

Project management in SCRUM

SCRUM is a project management methodology based on empirical process control theory, which is consistent with the values of the Agile manifesto (2001). This is not a restrictive work methodology but rather a framework that allows...

Mateusz Lesniak
The Codest

The Codest Core Value #1

The Codest believes in four crucial values that are the core of all actions taken by The Codest teams. In this article, our CEO and co-founder, Greg Polec, explains what acting fast and focusing on the bigger picture means to us.

Greg Polec
The Codest

The Codest's Success Story: Meet Lukasz Brzeszcz

This time the star of The Codest Success Story is Lukasz Brzeszcz, our Ruby software developer and programmer. How did Lukasz’s journey with The Codest begin and what helped him to become an awesome manager? Read this article to...

Monika Krupa
The Codest

The Codest's Success Story: Meet our Finance Lead Iza

In this article series, we share the stories of The Codest teammates who have had an impact on the present shape of our company. In the following piece, we ask our Financial Lead, Iza, some questions about her career at The...

Monika Krupa

Subscribe to our knowledge base and stay up to date on the expertise from industry.

About us

We are an agile software development company dedicated to empowering our clients' digital transformation projects and ensuring successful IT project delivery.

    United Kingdom - Headquarters

  • Office 303B, 182-184 High Street North E6 2JA London, England

    Poland - Local Tech Hubs

  • Business Link High5ive, Pawia 9, 31-154 Kraków, Poland
  • Brain Embassy, Konstruktorska 11, 02-673 Warsaw, Poland
  • Aleja Grunwaldzka 472B, 80-309 Gdańsk, Poland

    The Codest

  • Home
  • About us
  • Services
  • Case studies
  • Know how
  • Careers

    Services

  • PHP development
  • Java development
  • Python development
  • Ruby on Rails development
  • React Developers
  • Vue Developers
  • TypeScript Developers
  • DevOps
  • QA Engineers

    Resources

  • What are top CTOs and CIOs Challenges? [2022 updated]
  • Facts and Myths about Cooperating with External Software Development Partner
  • From the USA to Europe: Why do American startups decide to relocate to Europe
  • Privacy policy
  • Website terms of use

Copyright © 2022 by The Codest. All rights reserved.

We use cookies on the site for marketing, analytical and statistical purposes. By continuing to use, without changing your privacy settings, our site, you consent to the storage of cookies in your browser. You can always change the cookie settings in your browser. You can find more information in our Privacy Policy.