Editing code of react npm modules in node module folder

Question

Is it possible to change code of npm modules in the modules folder? I assume this is not recommended practice, are there any other ways achieving this? Currently, I tried changing the code in the module's directory but the changes doesn't seem to apply. Thanks in advance.

Answer 1

Another solution if the module is relatively small is that you can just copy the files over:

Once you copy the files over, you just import them as you would any other file in your project.

The caveat is that you will lose out on any updates or bug fixes to the original package. However, on the positive side, if what you require is fairly simple and you are not worried about the updates, this may be a viable solution. I had the same issue and found this suited my needs quite well and was very simple to do so.

In all cases, you should be mindful of the license of the original package. Most open-source software allows for modifications, but some licenses might have restrictions or obligations that you need to follow.

Remember to test the package thoroughly after making changes, as modifications could potentially introduce bugs.

Answer 2

This is horribly annoying indeed and I wish everyone would get off their high horse and quit saying that "it's a bad idea and you should fork the module etc.".

So I have this module and want to test a few small modifications to it, and see how the app reacts.

So I want to go into the module code and make the modifications directly. Now indeed the module code would often be built so yeah you gotta be careful and need some luck.

Now the "proper" way:

1. fork the module repo
2. replace module dependency with my forked repo
3. make the changes on my forked repo
4. push the change to online repo
5. update npm modules, rebuild and wait for changes to be applied
6. test the app with the modified module

So for every new experimental change on the module code I should do stap 4 to 6 again?

Indeed if I just change the built module code directly it doesn't do a think for some frustrating reason.

I have found that deleting node_modules/.cache would force the build process and again that this time the changes to the module codes will be applied.

However it's a very slow, CPU intensive process.

What I ended doing is that I have a module that I want to mess with which is actually just a single file so I just copied it to a directory in my src folder and require it by path so now changes are instant and there is no confusion

Answer 3

I was using Vite and wanted to make some temporary edits to a package in the node-modules folder, and nothing was happening as expected.

Turns out that Vite does some caching that was new to me, and you have to pass --force to the start command to get Vite to see any node_module updates you make.

From their docs:

If for some reason you want to force Vite to re-bundle deps, you can either start the dev server with the --force command line option, or manually delete the node_modules/.vite cache directory.

Answer 4

In my case, I could not accept all the above approaches because I needed to make a few minor changes. So I imported some necessary classes from the node_module folder and overrided them in my source tree.

Let's assume we need to change the class "Computer" from the installed node_module: computer.

import
{
    RAM,
    Display,
    HardDisk
} from "computer"

class Computer{
    constructor() {
        this._ram = new RAM();
        this._display = new Display();
        this._hardDisk = new HardDisk();
    }

    ...
}

Then you can change like this, for example in your source tree.

import
{
    RAM,
    Display,
    HardDisk
} from "computer"

// assume you made additional classes, Keyboard, Mouse 
import {KeyBoard, Mouse} from "./mysourceTree"

class Computer{
    constructor() {
        this._ram = new RAM();
        this._firstDisplay = new Display();
        this._hardDisk = new HardDisk();
        
        
        this._keyBoard = new Keyboard();
        this._mouse = new Mouse();
    }

    ...
}

Answer 5

You can also use patching.

In React Native world, that works quite reliably - so I would guess it would work also in React world and many other worlds that rely on npm.

Patch-Package

is a library that works both with npm, and yarn (note: for yarn, see their installation instructions). You can make patches to local folders, libraries in node_modules (also nested), or apply patches only for dev dependencies (ignore patches in production buils).

Link is just here: https://www.npmjs.com/package/patch-package

1.Making patches

First make changes to the files of a particular package in your node_modules folder, then run

npm patch-package package-name-where-you-made-changes
// or
// yarn patch-package package-name-where-you-made-changes 

If you are trying to patch a nested package at, e.g. node_modules/package/node_modules/another-package you can just put a / between the package names:

npx patch-package package/another-package

It works with scoped packages too.

npx patch-package @my/package/@my/other-package

2.'/patches' folder

If this is the first time you've used patch-package, it will create a folder called patches in the root dir of your app. Inside will be a file called package-name+0.44.0.patch or something, which is a Git diff between a normal old package-name and your fixed version.

3.Sharing patches with the team

Simply, commit files (patches) in the 'patches' folder to the repo.

When other team-member (or CI service) runs npm install, patches are executed automatically (using npm post-install script underhood) - see patch-package official docs, if you want to customize this behavior (e.g. exclude some patches, etc).

4.TIP:

If the package is hosted at Github (and you are logged in), you can run the same patch-package command with --create-issue param, so it will automatically create a pull-request with the applied patches in the main repo (so the maintainers could fix the issues):

npm patch-package package-name-where-you-made-changes --create-issue
// or
// yarn patch-package package-name-where-you-made-changes

5.TIP:

To revert patches, run it with --reverse param:

npm patch-package package-name-where-you-made-changes --reverse

Answer 6

For me te best approach is, as like @Kevin Raoofi said, clone the package and publish my own, then download mine in a specific folder, where there are only "myNpmPackages".

Then:

• in your project, install your clone
• put "*" in your json in order to have always the pkj updated
• edit the package (in your "myNpmPackages" folder)
• change the version number
• npm publish
• in your project, npm install

Answer 7

Of course you can change the contents of packages in node_modules as it's a standardized format. However, you shouldn't do that because you should be committing your changes and redistributing them.

Unfortunately, the solution to this is kind of non-trivial and it's something I've struggled with in the past.

npm link

The first approach is to clone the repo locally and use npm link to use it in your project.

npm link ../path/to/my/proj

The drawback with this approach is that you still have to manually download the repository to use it and npm link makes your linked version the package to use globally on your system which may have unintended side effects. That being said, npm link is probably the best approach if you want to locally test changes to your package and contribute them upstream.

Use a forked git repo

You could also directly install it from a forked git repo by doing:

npm install --save $GIT_REPO_URL

But with this approach, you need to have the credentials to access the git repo and thus additional complexity arises when you are dealing with private repos and the such, particularly when dealing with CI environments. Also, you should include a commitish so that you can get reproducible builds -- it's sort of a pain to develop this without using npm link, though. You can consult the npm documentation for other install options or for more specifics. This is a pretty good approach if you don't have to worry about any of those things.

Local npm module

Once you've made your changes, you could also install the forked version into your project like so:

npm install --save ../path/to/my/proj

However, then, you'd effectively have the other NPM project a part of your project with something like git submodules, git subtrees, or using a monorepo. This may be a good approach for a team, but is probably overkill for what you're trying to do and there's seriously a lot of tooling that you need to think about to make this a good approach.

Publish your own npm module

Unfortunately, all the prior approaches kind of assume that the packages either do not have a build process or that they get built automatically with something like npm's postinstall scripts. However, some npm modules are written by publishing a specific build directory, making what's on npm significantly different from the source.

In these cases, you need to publish your builds to somewhere that npm can install from. This includes things like a public scoped package, a private npm repositories, or publishing your npm module to a personal artifact server.

Answer 8

It is not recommended to modify packages in node_modules directly, since your changes will be gone when you reinstall the package, and you can't share your changes with others. Consider e.g. forking the project on GitHub and make your changes there, and use that as the package instead.

It still works to modify packages in node_modules if you just want to experiment. If the main field of the package's package.json points to a build file, you might have to change this field to the source entry file instead, or build the files yourself after every change in the source.