Support multiple patches per package

[jamesreggio]

I've been manually patching React Native for quite some time and I love the idea of this tool. It makes extracting a patch so much easier than the manual process I'm used to using.

The one thing that stands in the way of my complete adoption of patch-package is its lack of support for multiple patches upon the same package. I like to separate my patches by concern, and it'd be nice if patch-package allowed a third segment in the patch name that can be customized by the user.

For example, it'd be great if I could split my one mega-patch into the following three patch files:

patches/react-native+0.52.0+babel.patch
patches/react-native+0.52.0+cookies.patch
patches/react-native+0.52.0+scrollview.patch

patch-package could apply the patches in lexically-sorted order. If the order of patch application matters, the user could include a sorting ordinal in the custom third segment, like such:

patches/react-native+0.52.0+00-scrollview.patch
patches/react-native+0.52.0+01-cookies.patch

The trickiest part of this will be excluding existing patches at the time that a new patch is extracted from a package. I'm not entirely sure how to handle that, but I'm also unconvinced that support for multiple patches needs to hinge on first-class support for extracting and isolating multiple patches. For now, if you want to use this power-user feature, you would just need to ensure that each patch is authored on a clean base package.

[ds300]

Cool feature request! I'd love to have this as an option for power users.

I'm happy to provide guidance if you're interested in working on this. Probably won't get around to it myself any time soon.

[jamesreggio]

I'd be happy to do the implementation if you're okay with me just tackling the patch application portion first. How does that sound to you?

(And any pointers would be appreciated.)

[ds300]

I think that's the trivial part and it makes sense to prototype the patch generation/updating first, since design decisions there might affect how the patch application works.

[jamesreggio]

Aw shucks, you're gonna make me eat my vegetables before I get my steak.

Alright then. I probably won't circle back to this for a while yet, but we'll see.

[ds300]

Hah, sorry, I was in work mode. I forgot that people also code for fun :-) If you want to build the patch application first, go for it. Often doing the easier bits first is a great way to get motivated for tackling the larger problem.

…

On Wed, 28 Feb 2018, 23:29 James Reggio, ***@***.***> wrote: Aw shucks, you're gonna make me eat my vegetables before I get my steak. Alright then. I probably won't circle back to this for a while yet, but we'll see. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#43 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABL1qfZe4oYEo3wT8VfkGiXUl5oEx194ks5tZeFdgaJpZM4SXIiJ> .

[jamesreggio]

Sounds good.

I slept on it and think that a good approach to capturing the patch would be similar to git add -p, where you get an interactive prompt for staging the patch. Given that you're already using git under the hood, this actually shouldn't be too much of an undertaking.

In summary, I'd add the following options to the CLI:

---

• --interactive, -i

  Interactively choose hunks of changes to include in the patch. Similar to git add --patch.

• --name [name], -n [name]

  Add an optional name identifier to the patch's filename.

  [name] may contain letters, numbers, hyphens, and underscores.

---

The applicator would then be modified to lexically sort the patches and then ignore the name's patch segment (though It would echo the name it as it reports status).

// The patch filename regex would go from this:

/^(.+?)(:|\+)(.+)\.patch$/

// to this:

/^(.+?)(:|\+)(.+)(?:(:|\+)(.+))?\.patch$/

// In case you haven't seen it before, (?:[pattern]) indicates a non-captured group.

WDYT of that approach?

[RocketPuppy]

This would be really helpful in normal usage as well. I see added #37 to fix a bug with cached node_modules and partially applied patches. A sequence of multiple patches to be applied would also be helpful there, and shouldn't require reverting old patches.

[DanielRuf]

Bump, we would also need this feature.

[DanielRuf]

Workaround for us at the moment: some sort of structured collection which I am currently building at https://github.com/DanielRuf/patches

[DanielRuf]

Should similar or same like it is done in https://github.com/cweagans/composer-patches

[avrahamcool]

Bump, I would love to see this features live.

[ds300]

Not sure whether I want to support this feature or not.

On the one hand, it makes it easier to group and understand related changes.

On the other hand, it's a very complicated UX problem, and would likely balloon the surface area of the cli.

Also part of me feels like if the changes are so significant that grouping them makes them significantly easier to understand, then it's probably a good indication that forking the library is the way to go.

So feature is very low on my priority list. I don't think I'll ever work on in myself or approve a pull request for it unless someone designs a UX that feels really good for generating and managing the stacked patch files.

[avrahamcool]

if I understood the other comments correctly, the main thing we want here is to be able to group changes into small independent chunks, so we can have more control on which patches we need to apply over the original package.

lets say one of the changes we patched is later fixed by the maintainer of the package, but the other are not - we can just delete this specific patch file.

the part that is bothering you is the interactive UI for choosing the parts of the changes that should be grouped together.
what if we took a different approach at this? we don't need to specify anything.

• if it's the first time we patch a package:
  every change that is made to the original package will be taken into the patch file.

• if the package already been patched before:
  we take only the "new" changes, and create a patch file for them.
  this can be done by installing a clean version of the package - and applying all of the old patches in a sequence, and only then applying the diff between the result and the user edited package.

(it;s clear that the first scenario is actually a private case of the second one.. but it's clearer to understand in that way)

I hope I didn't miss the point completely..

[ds300]

Yeah that would work for creating patch files! But what if you want to go back and make changes to a previous patch file?