3

What is the etiquette around forking and NPM?

Consider the following sequence of events:

  1. There is an existing open source project published on GitHub (or similar) under some standard permissive license (e.g. MIT) that is also published to NPM. That package has a relatively high download rate on NPM. The NPM package name accurately and concisely describes the intent of the package.
  2. A user unaffliated with the library discovers the package & library but notices that there are some bugs or other improvements to be made. The new user opens some GitHub issues outlining the bugs/improvements and then forks the repo and opens a PR where those problems are addressed.
  3. There is no immediate or short term response from the maintainer(s).
  4. While waiting for the maintainer to acknowlege the PR (either reject, merge or otherwise request changes), the new user
    • notices further changes that need to be made
    • needs their changes to be consumed by other upstream packages (that may or may not be open source)

Which course of action is most beneficial to the new user and applies reasonable etiquette? Some possibilities include:

  • Having NPM consume their fork (based on GitHub url)
  • Publishing a new package to NPM based on their fork
  • 1
    I'm not familiar with NPM in particular, what does “having NPM consume their fork (based on GitHub url)” mean? Is this about changing metadata of a package published to NPM, or is this about adding a dependency on a GH repo instead of on an NPM-published package? – amon Jun 27 '18 at 20:32
  • @amon the latter. “having NPM consume their fork (based on GitHub url)” refers to having downstream dependencies be configured to fetch the package as code from github as opposed to retrieving a published artifact available on NPM servers. – Jacob Horbulyk Jun 27 '18 at 20:56
  • What do you mean that the user "needs their changes to be consumed by other upstream packages". If you fork a package, there is no obligation that the maintainer accept your version or your changes, and certainly there is no obligation that other people switch to use your version instead. – Brandin Jun 28 '18 at 14:59
3

If your PRs aren't being accepted, the best course of action is to published a scoped version of the package. You can do this even before you think that your PR is being ignored.

If you make substantial changes, and after a long while your PRs are still being ignored, then you could consider publishing it with a different name.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.