patch-package icon indicating copy to clipboard operation
patch-package copied to clipboard

Integrate with open source PR flow?

Open karlhorky opened this issue 6 years ago • 14 comments

Hey, thanks for this project! Just getting reminded of it by @sibelius and it is still awesome!

What if we could have the best of both worlds (PRs to update upstream + patches to avoid having to npm publish)? Workflow:

  1. You open a PR with the change that you would like
  2. You click a button and an automated script (bot? GH action?) copies your change to a repo of your choice and holds a reference to it
  3. Potentially other users also do the same as 2.
  4. You make a change to the PR
  5. The automated script creates PRs with the patch files to all referenced repos
  6. The PR gets merged
  7. The automated script creates PRs to all referenced repos, deleting the patch file and bumping the version number

karlhorky avatar May 07 '19 16:05 karlhorky

Cool idea! This sounds like a separate project that anyone could implement. I'll leave this issue open for a while to foster discussion, but I don't have the inclination to work on this myself. Thanks for the suggestion 👍 🙌

ds300 avatar May 07 '19 17:05 ds300

You can add a .patch on pul requests

https://patch-diff.githubusercontent.com/raw/devhubapp/devhub/pull/125.patch

maybe this could be a good start

sibelius avatar May 07 '19 17:05 sibelius

a nice POC here https://github.com/jonnyburger/import-patch

sibelius avatar May 07 '19 18:05 sibelius

This is a cool idea, it gets a bit tricky when code has to be transpiled between /src and /dist though :-/

orta avatar May 08 '19 12:05 orta

yep @orta that's part of the reason I ended up abandoning the opposite idea (i.e. turning a patch file into a PR automatically)

ds300 avatar May 08 '19 14:05 ds300

What about the other way around?

  1. you work on your patch locally
  2. when you run patch-package x, it would look for the repository of x in its package.json and if:
  • there is one
  • it's is on GitHub
  • the patched files aren't in dist or build (or whatever heuristic we can imagine to detect transpiled files)
  1. ask the user if they want to open a PR with the patch and somehow open a PR for them (probably need their GH token)

mathieudutour avatar May 13 '19 10:05 mathieudutour

Interesting, could work for the code without a build step!

And maybe for the code with the build step, we could also achieve something similar, if Step 1 would look more like:

1a. Install package tooling locally (edit: with source files too) 1b. Make your changes to the source files & build 1c. Specify to patch-package which files are "built" files, to be used for both the patch and the PR

karlhorky avatar May 13 '19 11:05 karlhorky

It could work for packages that ship their sources in addition to the transpiled files but I'm not sure it's the majority?

mathieudutour avatar May 13 '19 11:05 mathieudutour

Right, yeah... hm... I guess for that to work the whole package including source needs to be downloaded for this workflow to work... updated my list above.

karlhorky avatar May 13 '19 11:05 karlhorky

This issue seems specific to GitHub pull requests, so I've opened another issue to resolve the problem of how to import source in general without hand-editing node_modules. I'd love any feedback or suggestions.

christianbundy avatar Jan 11 '20 16:01 christianbundy

Oops, forgot the link: https://github.com/ds300/patch-package/issues/197

christianbundy avatar Jan 11 '20 16:01 christianbundy

I think having a patch repository would be a safer/easier approach. This could even benefit from GitHub gists API, making it quite cheap or entirely free to achieve.

Is @ds300 open for a PR on this idea? I can definitely give it a try. I think something like this would cut it:

npx patch-package apply [project-name]+[version]+[unique-patch-reference]

This command would try to apply the given patch to the given project, and create a new patch under ./patches/[project-name]+[version].patch as usual. PR URLs could ideally used the same way directly, as after it's applied we won't event request from source again.

Issues:

  • Applying multiple patches to same project might lead to conflicts. These would still have to be solved manually, but it's in my opinion an acceptable issue.
  • After applying an external patch, we would no longer have a reference to the source. We could, however, have it stored somewhere under ./patches/, such as ./patches/external.json, with a list of previously applied patch refs and URLs to their origin.

lucasconstantino avatar Aug 06 '20 12:08 lucasconstantino

Nice, some new movement on this idea (comment by @sw-yx): https://twitter.com/swyx/status/1366314693095170053

karlhorky avatar Mar 01 '21 22:03 karlhorky

patch-package is already awesome, but this would honestly be a real game changer. Right now I feel the process of making a PR makes me lazy in opening PRs from my patches, and I'm sure many feel the same. This means many patches get stuck locally when they could benefit everyone, and also means we end up with more patches than we'd otherwise need.

If it was as easy to open a PR as an issue from patch-package it would really close the loop on the patching experience! 🚀

robertherber avatar Jan 04 '23 08:01 robertherber