Publish fork of GitHub project to new NPM module but keep option to merge with original?

Question

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

Answer 1

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.

Answer 2

I have encountered similar problems many times but this time I wrote npm-fork for this.

To publish forks of the original package(s):

1. Commit or stage changes you don't want to get messed up with patches.
2. Build the project.
3. npm-fork publish --scope @user or npm-fork publish --scope @user --package @origin/* for monorepo.

It will patch package.json and JavaScript files (require/import/export) listed by npm-packlist (i.e., files that will eventually be packed) with prerelease versions, publish it using npm publish, and git restore . after publishing.

To patch without publishing and restoring, just run npm-fork patch instead of npm-fork publish.

Answer 3

@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.