4

I've pulled down a node module using NPM, and added it to package.json. However there was a need to change some of the module's code as it didn't meet my requirements 100%.

Typically when I'm working with node and git I would ignore the node_modules directory and use npm install when deploying to a server.

I'm wondering what best practise would be in my scenario, is there a way of defining a module in package.json that should be ignored if it already exists locally when running npm install? Is this already the default behaviour for all modules? How would that work if someone ran npm update? I would assume the latest version of that module would be pulled down and would overwrite my changes?

Alternatively I've thought about forking the original git repo for the module, republishing my fork to NPM and then using that instead.

Tips and ideas would be greatly appreciated :)

broguinn
  • 591
  • 2
  • 14
Jamie Street
  • 1,527
  • 3
  • 14
  • 32

1 Answers1

5

Alternatively I've thought about forking the original git repo for the module, republishing my fork to NPM and then using that instead.

You have the right idea here. Under NPM, you definitely don't want to split your concerns between hosted and version control-tracked resources. Fork the repo, and then answer this question: if you add the functionality to the existing module, is the pull request likely to be merged and published to NPM soon enough for you?

If the answer is no because the functionality doesn't meet the intentions of the original module, you're better off creating your own, making sure to note your fork in the README.

If you're waiting on the PR, you have an option in the interim. NPM lets you link directly to your fork's .git file.

broguinn
  • 591
  • 2
  • 14