6

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
Improve this question
3
  • 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, 2018 at 20:32
  • 1
    @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, 2018 at 20:56
  • 1
    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, 2018 at 14:59

1 Answer 1

Reset to default
6

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.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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