berry: [Bug?]: yarn patch generated unparsable patch: URL

Self-service

  • I’d be willing to implement a fix

Describe the bug

My company uses an internal package registry where all npm packages are fetched from. This is configured in ~/.yarnrc.yaml (company name replaced with example)

npmRegistries:
  "https://packages.example.com/artifactory/api/npm/npm-remote":
    npmAlwaysAuth: false
npmScopes:
  example:
    npmRegistryServer: "https://packages.example.com/artifactory/api/npm/example-npm"
    npmPublishRegistry: "https://packages.example.com/artifactory/api/npm/example-npm"

The result of this is that the resolution for the package in yarn.lock looks like this:

  resolution: "@example/eslint-plugin-example@npm:4.0.0::__archiveUrl=https%3A%2F%2Fpackages.example.com%2Fapi%2Fnpm%2Fexample-npm%2F%40example%2Feslint-plugin-example%2F-%2F%40example%2Feslint-plugin-example-4.0.0.tgz"

When I tried to patch this packing using:

$ yarn patch @example/eslint-plugin-example
# make edits
$ yarn patch-commit -s /private/var/folders/path/to/code/user
...

This generated a patch URL in package.json that looked like this:

```json
{
  ...
  "resolutions": {
    "@example/eslint-plugin-example@4.0.0": "patch:@example/eslint-plugin-example@npm:4.0.0::__archiveUrl=https%3A%2F%2Fpackages.example.com%2Fapi%2Fnpm%2Fexample-npm%2F%40example%2Feslint-plugin-example%2F-%2F%40example%2Feslint-plugin-example-4.0.0.tgz#.yarn/patches/@example-eslint-plugin-example-npm-4.0.0-bab1aa1587.patch"
  }

}

(Then I fixed the version range in that resolution as described in https://github.com/yarnpkg/berry/issues/4231#issuecomment-1072847435 )

Finally, running yarn to apply the patch gives this error:

$ yarn
➤ YN0000: ┌ Resolution step
➤ YN0001: │ Error: Patch locators must explicitly define their source
    at xue (/Users/lhunt/.node/corepack/yarn/3.2.2/yarn.js:733:658)
    at dE (/Users/lhunt/.node/corepack/yarn/3.2.2/yarn.js:733:978)
    at iO.bindDescriptor (/Users/lhunt/.node/corepack/yarn/3.2.2/yarn.js:736:2747)
    at wd.bindDescriptor (/Users/lhunt/.node/corepack/yarn/3.2.2/yarn.js:391:1082)
    at wd.bindDescriptor (/Users/lhunt/.node/corepack/yarn/3.2.2/yarn.js:391:1082)
    at reduceDependency (/Users/lhunt/.node/corepack/yarn/3.2.2/yarn.js:390:29055)
    at tA.reduceHook (/Users/lhunt/.node/corepack/yarn/3.2.2/yarn.js:392:3584)
    at ee (/Users/lhunt/.node/corepack/yarn/3.2.2/yarn.js:439:6759)
➤ YN0000: └ Completed
➤ YN0000: Failed with errors in 0s 23ms

I was able to work around this issue by modifying the patch: URL like this:

{
  ...
  "resolutions": {
    "@example/eslint-plugin-example@^4.0.0": "patch:@example/eslint-plugin-example@npm:4.0.0#.yarn/patches/@example-eslint-plugin-example-npm-4.0.0-bab1aa1587.patch"
  }
}

It appears the presence of ::__archiveUrl=https... breaks the parsing of the patch URL in yarn.

To reproduce

(as explained above)

edit: see reproduction in comment below https://github.com/yarnpkg/berry/issues/4711#issuecomment-1960736169

Environment

System:
  OS: macOS 12.5
  CPU: (10) arm64 Apple M1 Pro
Binaries:
  Node: 16.16.0 - /private/var/folders/78/vv5cyf6570xcqbsy0r2nfyfw0000gn/T/xfs-99d9804c/node
  Yarn: 3.2.2 - /private/var/folders/78/vv5cyf6570xcqbsy0r2nfyfw0000gn/T/xfs-99d9804c/yarn
  npm: 8.11.0 - ~/Library/Caches/fnm_multishells/21303_1659328957074/bin/npm

Additional context

No response

About this issue

  • Original URL
  • State: open
  • Created 2 years ago
  • Reactions: 3
  • Comments: 15 (6 by maintainers)

Most upvoted comments

I found this article quite helpful to understand the bug and how to work around it: https://charles-stover.medium.com/patching-packages-in-yarn-berry-72e4ded29a56

For documentation’s sake, I fixed this by changing %3A%3A to :: before each __archiveUrl= and by moving #~/.yarn/patches/... to before the :: in each instance as well.

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! 🌟