I’ve been working with a Node.js project that uses the jsdom library. I discovered a bug in the package and had to manually fix it by editing files directly in the node_modules/jsdom/lib/jsdom/level2/languages directory. The fix works perfectly on my local machine.
Now I need to deploy this application to a production server. What’s the recommended approach for handling npm packages that have been manually modified? I’m concerned that running npm install on the server will overwrite my changes. Are there any standard practices for managing customized dependencies in Node.js deployments?
Another viable option is using npm link for local development combined with a private registry approach for production. I encountered similar issues with modified packages and found that creating a tarball of your fixed version works well. After making your changes, navigate to the jsdom directory and run npm pack to generate a .tgz file. Then reference this tarball directly in your package.json using a local file path or upload it to a private registry. This method gives you complete control over the exact version being deployed and eliminates the risk of overwrites during production installs. The downside is you need to manually track upstream changes, but for critical fixes it provides the most predictable deployment behavior.
i totally agree! forking it on github is smart. also, you can keep it updated easier this way instead of dealing with manual fixes every time. just remember to check for any updates on the original repo too!
I’ve dealt with this exact situation before and learned the hard way that modifying node_modules directly is asking for trouble. What worked for me was using npm’s patch-package tool. You install it as a dev dependency, make your changes to the files in node_modules, then run npx patch-package jsdom. This creates a patches directory with your modifications that gets automatically applied after every npm install. It’s much cleaner than forking because you don’t have to maintain an entire repository for just a small fix. The patch files are version-specific though, so you’ll need to recreate them if you update the package version. Been using this approach for over a year now across multiple deployments and it’s saved me countless headaches.