27

A high quality open source repo exists on GitHub and NPM, with a wide user base.

I've forked the project and made a substantial extension. I think is ready to merge back. But (appropriately) its the project owner who gets to make that call not me. And it's now been several weeks without reply.

Several users have asked on the repo issue discussion that this be merged back, and more have contacted me directly to publish to NPM as a separate project.

Serious developers can get the new version via GitHub, but it has just the raw source, not the catenated/minified/tailored versions as the README says not to run make dist until it's merged back and the version number incremented.

I think it should be as simple as creating a fork of this fork, and publishing that as a new NPM module. But GitHub doesn't allow me to do that ("You're already looking at this project")

Is there a way that I can publish this as a new NPM module, but still retain the options for

  1. my fork to submit a pull request to the original
  2. my fork to fetch upstream changes from the original
  3. my sub-fork to fetch upstream changes from my fork (and thus the original)

Do I create a new GitHub account under a new email address?

Forking a fork of my repo in GitHub

Community
  • 1
  • 1
prototype
  • 7,249
  • 15
  • 60
  • 94
  • 6
    You shouldn't need a new fork just to publish to npm. You can just use your existing fork and keep 2 branches: a "stable" branch that you publish to npm, and a work-in-progress branch that constantly syncs changes with the original project. – user2943490 Jun 12 '15 at 06:28
  • @user2943490 your comment is the answer. It is possible to publish a branch of a repo (other than `master`) to npm and bower. – prototype Jun 13 '15 at 01:18

2 Answers2

22

How to fork & patch npm modules

  1. Fork the project on GitHub.
  2. Clone the fork to your machine
  3. Fix the bug or add the feature you want.
  4. Push your commits up to your fork on GitHub (Use a branch if you wish to create a PR for the original repo).
  5. Open your fork on GitHub, and find and copy the SHA of the latest commit you made.

  6. Open up your package.json file, and replace MODULE, USER, REPO, and SHA with the info from the GitHub repo.

    "MODULE": "https://github.com/USER/REPO/tarball/SHA",

    eg: to get a tarball link from this commit

    "react-remarkable": "https://github.com/HelloKip/react-remarkable/tarball/9549e776136096b827f3a0823329ad997416e364",

  7. Run npm i to install the module dependencies.

  8. Profit!

Adapted from debuggable.com and cmwelsh.com.

OroshiX
  • 712
  • 1
  • 8
  • 28
Beau Smith
  • 33,433
  • 13
  • 94
  • 101
  • 7
    This doesn't work for packages that need to be processed (e.g. via `prepublish` script) before consumption, does it? – jacobq Oct 16 '18 at 17:36
  • @iX3 - Sorry, I don't know… but now I'm curious. – Beau Smith Oct 16 '18 at 18:31
  • 2
    This is good info, but it doesn't answer the original concern about the package needed to be processed (transpiled, minified, etc.) before use. – GaryO Feb 24 '21 at 18:07
  • 2
    This article explains how to compile your forked version using a `postinstall` script. https://link.medium.com/hljD5UiRdeb – el-lugy Feb 27 '21 at 17:02
  • 2
    Basically this ```"scripts": { ... "postinstall": "cd ./node_modules/my-forked-project && npm install && npm run build" }``` – el-lugy Feb 27 '21 at 17:03
  • Are there other conditions in which this is expected to fail? Something to do with dependencies in sub-packages? Any suggested solutions? More details -- any tips appreciated: I tried to security-patch a [vulnerable dependency](https://github.com/JamesKyburz/aws-lambda-ws-server/issues/10) in [forked repo](https://github.com/Arakade/aws-lambda-ws-server/commit/59b98e4c43b6816fec75f9164c0d75feb3e96a2e) but, while the packages appeared correctly in `node_modules`, module loading said it couldn't be found!? (`Cannot find module 'aws-lambda-ws-server'` even though paths fine in DEBUG) – Arkade Jun 22 '23 at 10:33
4

@user2943490 gave you the correct solution to use branches instead of additional forks.

Let me expand this to answer your questions about still being able to being able to push or pull in several directions. The way git, or rather its data structures, are designed makes it so that you can always push and pull between arbitrary repositories, no matter what. It makes no difference even if they never had a common ancestry.

Yes, you can get wild conflicts, and obviously if you try to merge completely unrelated files, chaos will likely ensue, but it will still be possible. Git only ever cares about the actual contents of the files, not about where they were forked from.

In your example, as you will have common commits with the upstream, it won't ever be a problem.

AnoE
  • 8,048
  • 1
  • 21
  • 36