o

Sometimes your dependency does everything right except that one little detail that ruins everything. This tutorial will teach you to change the code of one of your dependencies in a way that if you install the dependency somewhere else your code changes will still be applied.

This only works with open-source dependencies. This is not a good practice but the last resort solution. You should find a more maintainable solution in the long run.

This is the kind of knowledge you either learn from someone or one day you go oh that's how you do it . It comes down to forking the original project, making the changes, and linking our fork in the package.json of our project so that it will download our library and not the original when we install the packages.

To achieve this we will have to complete the following steps

Find where the dependency is hosted

Fork the project and make the changes you desire

Override the projects dependency link with your fork in package.json

Find where the project is hosted

Most projects that you install are hosted on npm. If this is not the case you should look in your package.json the URL to the where your dependency is hosted

In npm :

“check-md” : “^1.0.0” Somewhere else:

“myLib” : “https://xxx.com/thatguy/mylib`

Once you have found where the code is hosted you will need to fork it (or copy it and host it yourself somewhere, take care for licenses). For the purpose of explaining the most common cases, we will cover a library on GitHub that is called check-md .

Fork and edit the project

Now we need to apply the changes to the library. This is done by applying the following steps:

Fork the project

Create a remote branch (optional but advised)

Edit the library to how you want it

Check for tests and linting and make sure you still pass them

Push your changes to your remote branch

Once we have found our github repository with the library’s code, let's fork it, clone it and create a branch on which we are going to push the changes.

Fork

On the top right of the github’s project page you should see a fork button. This will copy the project in your repositories list allowing you to freely make changes without affecting the original project.

Clone

After this, let's clone our fork and enter the directory.



$ cd check-md $ git clone git@github.com :bidoubiwa/check-md.git$ cd check-md

Remote branch

Create a branch that you can name to whatever changes you are applying on that library (just best practice to keep track of what you did).

In my case, I’m going to add a mode that will enforce md extension on links to markdown files. Thus, I will name my branch add_strict_md_mode .

# Create the branch locally and checkout to the newly created branch

$ git checkout -b add_strict_md_mode # Push the branch to remote git repository

$ git push origin add_strict_md_mode

Edit the project

In this example, I’m editing multiple files to add a mode to the library. Those files include the business logic files (index.js, bin.js), the testing files, and other files that needs mentions of my changes (readme and types).

Once I have applied all changes I use the built-in code testers and linters to check on any potential mistake I could have done. After which I add, commit and push the changes to my remote branch

# Push to my branch

git push origin add_strict_md_mode

Linking our library in the package manager

Now we have the library accessible remotely with the changes we want. This is great.

Let’s first remove the official dependency

# Using npm

npm remove check-md # Using yarn

yarn remove check-md

And replace it with our fork

# Using npm

npm install https://github.com/ <name> / <repo>[commit|branch|tag] # Using yarn

yarn add https://github.com/ <name> / <repo>[commit|branch|tag]

Which for me looks like this:

Now if you like inside package.json this is how my dependency changed:

# Before

"dependencies : {

check-md": "^1.0.0"

} # After

"dependencies : {

check-md": "https://github.com/bidoubiwa/check-md#no_missing_md_extension"

}

I added the branch name in the URL so that it will download changes from that branch and not from master . You could argue that the branch is useless. Which is true. I made my changes on a branch for two reasons. First is because I can better keep track of changes in a branch than on master . Second is because I can optionally propose the changes in a pull request to the original library. That way my changes will be applied to the official library and I could then go back and use their library instead of my forked version. This is the best-case scenario because they will keep maintaining it, but my fork will not be maintained.

Conclusion

With those changes made you can now install your packages and your dependency will have your desired changes.

One of the way you could have improved this is by creating a tag instead of a branch to make sure that you will always clone a workable version of your forked dependency. Since we never know what is added to a branch at any time, mostly if you're not alone on a project.

Finally, the best-case scenario would be that your changes are added to the official library. So consider making a pull request with your changes on their master branch. This way you can keep on using their library and not your forked version. This is better because they will maintain and update their library while your fork will not be updated.