[Bug?]: Patching a package that has already been patched creates a "patch of a patch"

[johndiiorio]

Self-service

• I'd be willing to implement a fix

Describe the bug

Running yarn patch against a package that has already been patched has unexpected behavior, sometimes creating a "patch of a patch". This is undesired, as I would like Yarn to merge my patch changes together, if applicable.

To reproduce

I'll use lodash for the examples but I believe this applies to any package.

Issue (1):

1. Start a new Yarn project and add a package: yarn set version berry && yarn add lodash
2. Run yarn patch lodash. Make a change in the extracted directory, then run yarn patch-commit -s <dir> && yarn.
3. Run yarn patch lodash again. At this point, I would expect to get the error message "Multiple candidate packages found" asking whether I'd like to patch the unpatched version or patched version of lodash, but no such message appears. The unpatched source of lodash is extracted.

Issue (2):

1. Start a new Yarn project: yarn set version berry.
2. Create a workspace and add a package to one of them: mkdir my-workspace && touch my-workspace/package.json
3. Add "workspaces": ["my-workspace"] to the root package.json
4. Add the following to the my-workspace/package.json:

{
    "name": "my-workspace",
    "dependencies": {
        "lodash": "4.17.21
    },
}

5. Run yarn patch lodash, make a change in the extracted directory, then run yarn patch-commit -s <dir> && yarn
6. Run yarn patch lodash again, note that unlike in (1), the "Multiple candidate packages found" error message is displayed.
7. Run yarn patch lodash@patch:lodash@npm..., make a change in the extracted directory, then run yarn patch-commit -s <dir>
8. Note that there are now two patches in .yarn/patches, and the package.json resolutions field implies a "patch of a patch"

"resolutions": {
    "lodash@4.17.21": "patch:lodash@npm%3A4.17.21#.yarn/patches/lodash-npm-4.17.21-6382451519::version=4.17.21&hash=b68992&locator=root-workspace-0b6124%40workspace%3A.#.yarn/patches/lodash-patch-af7531f881
}

9. Running yarn at this point prints an error: "Patch locators must explicitly define their source".

Environment

System:
  OS: Linux 5.15 Arch Linux
  CPU: (16) x64 AMD Ryzen 7 PRO 5850U with Radeon Graphics
Binaries:
  Node: 17.1.0 - /tmp/xfs-57237fea/node
  Yarn: 3.1.1 - /tmp/xfs-57237fea/yarn

Additional context

It is possible to work around (2) by selecting the unpatched version of the package, remaking all previous patch changes, then adding in any new changes. However, I would expect that Yarn would handle this case automatically.

[yarnbot]

Hi! 👋

This issue looks stale, and doesn't feature the reproducible label - which implies that you didn't provide a working reproduction using Sherlock. As a result, it'll be closed in a few days unless a maintainer explicitly vouches for it or you edit your first post to include a formal reproduction (you can use the playground for that).

Note that we require Sherlock reproductions for long-lived issues (rather than standalone git repositories or similar) because we're a small team. Sherlock gives us the ability to check which bugs are still affecting the master branch at any given point, and decreases the amount of code we need to run on our own machines (thus leading to faster bug resolutions). It helps us help you! 😃

If you absolutely cannot reproduce a bug on Sherlock (for example because it's a Windows-only issue), a maintainer will have to manually add the upholded label. Thanks for helping us triaging our repository! 🌟

[jose-elias-alvarez]

Implementing the ability to "patch a patch" would be a very nice improvement. In the meantime, does anybody have a good workflow for this? Manually modifying the patch files or generating new hunks with git diff --no-index technically works, but it's pretty error-prone.

[johndiiorio]

@jose-elias-alvarez Here's my workaround. It's not great but it does work 100% of the time.

1. Run yarn patch <package-name>. You'll get the error asking which version you'd like to patch.
2. Run yarn patch <package-name>, choosing the string from the output of (1) that includes the @patch substring.
3. Open the directory from (2) in an editor and make changes as necessary.
4. Run yarn patch <package-name> again, choosing the string from the output of (1) that doesn't include the @patch substring.
5. Delete the user directory of the output from (4), and replace it with the user directory of the output from (2).
6. Run yarn patch-commit -s <package-name> && yarn install, using the directory from the output of (4).

[jose-elias-alvarez]

@johndiiorio Excellent, thanks! This is not ideal but is far better than what I was doing. When I have some time, I'll take a look at the source and see what it would take to implement a fix.

[arcanis]

Note that I merged a few improvements on Yarn 4 (canary); might want to try a rc first, I think updating an existing patch should now be supported (can't search for the exact PR at the moment, but it should be easy to find).

[merceyz]

can't search for the exact PR at the moment, but it should be easy to find

Should be this one: #4218

[jose-elias-alvarez]

Note that I merged a few improvements on Yarn 4 (canary); might want to try a rc first, I think updating an existing patch should now be supported (can't search for the exact PR at the moment, but it should be easy to find).

Perfect, thank you! It looks like yarn patch --update $PACKAGE_NAME handles this workflow perfectly.

[merceyz]

Fixed in #4218

[arimendelow]

Is this released? It looks like it's included in the latest version of yarn, but...