[Bug]: Yarn patches are not applied for deps using `resolutions` #4231

milesj · 2022-03-16T21:18:20Z

Self-service

I'd be willing to implement a fix

Describe the bug

Short: Yarn patches (.yarn/patches) are not applied when node modules are restored from a cache (ignores the fetch step).

Long: In CI, we cache the .yarn/cache and .yarn/install-state.gz files based on the checksum of yarn.lock. This works pretty great and reduces the "fetch step" during yarn install down to 1 second. Overall, the entirety of yarn install takes less than 2 minutes (most of it is linking).

However, we've noticed the new patches do not get applied when we use this approach, while patches work locally. This is very apparent because builds crash in CI that were fixed by this patch, and the line numbers in the stack trace are pointing to the original pre-patch lines.

Since we have no way to apply patches manually, I'm not sure how to work around this. Busting the cache didn't work. And also caching .yarn/patches didn't work.

To reproduce

Our problem is unique to Buildkite CI but it can maybe be replicated with GitHub actions: https://github.com/actions/setup-node

Environment

System:
    OS: macOS 12.3
    CPU: (16) x64 Intel(R) Core(TM) i9-9880H CPU @ 2.30GHz
  Binaries:
    Node: 16.13.1 - /private/var/folders/93/p1hnsld57s79d4b503vnmq2w0000gn/T/xfs-b98bb0af/node
    Yarn: 3.1.0 - /private/var/folders/93/p1hnsld57s79d4b503vnmq2w0000gn/T/xfs-b98bb0af/yarn
    npm: 8.1.2 - ~/.nvm/versions/node/v16.13.1/bin/npm
  npmPackages:
    jest: ^27.4.7 => 27.5.1

Additional context

We're using Buildkite with the cache plugin:

steps:
  - plugins:
    - <cache plugin>:
        key: yarn-node-modules-{{ checksum "yarn.lock" }}-v1
        paths:
          - ./.yarn/cache
          - ./.yarn/install-state.gz

The text was updated successfully, but these errors were encountered:

merceyz · 2022-03-16T21:39:41Z

That's odd but when a patch is updated there should be a change to the lockfile which would invalidate the cache.

milesj · 2022-03-16T22:23:27Z

I actually spoke too soon. Busting the cache doesn't fix the problem, and a fresh install doesn't seem to be patching either in CI. I'm looking into other issues.

milesj · 2022-03-18T17:39:06Z

I also tried removing the cache entirely and the files are still not patched in CI. This is very confusing.

milesj · 2022-03-18T17:49:00Z

For example, this is the pre-patched code that fails:

if (opts.platforms) {
    // @ts-ignore
    platforms = (0, _lodash().pick)(platforms, opts.platforms);

    _cliTools().logger.debug('Skipping selected platforms');
  }

  _cliTools().logger.debug('Available platforms: ' + `${Object.keys(platforms).map(_getPlatformName.default).join(', ')}`);

  if (rawPackageName === undefined) {
    _cliTools().logger.debug('No package name provided, will link all possible assets.');

    return (0, _linkAll.default)(ctx, {
      linkDeps: opts.all,
      linkAssets: true
    });
  }

The return (0, _linkAll.default)(ctx, { is line 82, and this is part of the error stack thrown in CI.

  at linkAll (/workdir/workspaces/node_modules/@react-native-community/cli/build/commands/link/linkAll.js:96:31)
  at Object.link [as func] (/workdir/workspaces/node_modules/@react-native-community/cli/build/commands/link/link.js:82:33)

And this is our patch:

diff --git a/build/commands/link/link.js b/build/commands/link/link.js
index 9f0468ba3b7b71885b8ed31415a763f54adc15f7..82085e0913b48464b0a77fb91150f6cb9b8c8f26 100644
--- a/build/commands/link/link.js
+++ b/build/commands/link/link.js
@@ -71,6 +71,10 @@ async function link([rawPackageName], ctx, opts) {
     // @ts-ignore
     platforms = (0, _lodash().pick)(platforms, opts.platforms);
 
+    // We filter down the platforms but dont apply it to the context,
+    // which results in ios still being targeted elsewhere.
+    ctx.platforms = platforms;
+
     _cliTools().logger.debug('Skipping selected platforms');
   }

And the patch applied to the code locally:

if (opts.platforms) {
    // @ts-ignore
    platforms = (0, _lodash().pick)(platforms, opts.platforms);

    // We filter down the platforms but dont apply it to the context,
    // which results in ios still being targeted elsewhere.
    ctx.platforms = platforms;

    _cliTools().logger.debug('Skipping selected platforms');
  }

  _cliTools().logger.debug('Available platforms: ' + `${Object.keys(platforms).map(_getPlatformName.default).join(', ')}`);

  if (rawPackageName === undefined) {
    _cliTools().logger.debug('No package name provided, will link all possible assets.');

    return (0, _linkAll.default)(ctx, {
      linkDeps: opts.all,
      linkAssets: true
    });
  }

Line 82 is no longer return (0, _linkAll.default)(ctx, {, and is instead a blank line 4 lines up.

Yet after all this, CI is still failing with the original error. Is it possible for the patches to not be applied and failures to not be bubbled up?

milesj · 2022-03-18T17:54:47Z

One piece of context that may be useful is that this is running in a docker container.

milesj · 2022-03-18T18:47:47Z

So in CI I went ahead and cat the file that should be patched after yarn install, and it definitely does not have the patch applied. Just going to switch to patch-package.

milesj · 2022-03-18T18:54:01Z

I also noticed that the lockfile isn't showing the patch defined in resolutions: "@react-native-community/[email protected]": "patch:@react-native-community/cli@npm:6.4.0#.yarn/patches/@react-native-community-cli-npm-6.4.0-f99ee73e09"

So @react-native-community/cli is a transient dep, and I've also noticed that our other patches for transient deps (via resolutions) are not in the lockfile either. Only patches for non-transient deps are in the lockfile and do work. So maybe this is the actual bug @merceyz

But this still doesn't explain why it works locally and not in CI.

arcanis · 2022-03-18T19:13:53Z

It's very difficult to understand what might happen without a reproduction, unfortunately. We use patches at work without issues, so there's something very specific to your context - if we can't isolate what that is, we can't help you much 🙁

milesj · 2022-03-18T19:16:40Z

@arcanis Yeah I figured. Creating a reproduction will be impossible.

Does Yarn have any kind of debugging I can enable or something?

milesj · 2022-03-18T21:00:59Z

Enabled enableInlineHunks to debug more and noticed TS is failing to apply. Would that stop other patches?

➤ YN0066: │ typescript@patch:typescript@npm%3A4.5.5#~builtin<compat/typescript>::version=4.5.5&hash=ddd1e8: Cannot apply hunk #2
--
  | ➤ YN0000: │           }
  | ➤ YN0000: │       }
  | ➤ YN0000: │       ts.getEffectiveTypeRoots = getEffectiveTypeRoots;
  | ➤ YN0028: │ -     function getDefaultTypeRoots(currentDirectory, host) {
  | ➤ YN0028: │ +     function getNodeModulesTypeRoots(currentDirectory, host) {
  | ➤ YN0000: │           if (!host.directoryExists) {
  | ➤ YN0000: │               return [ts.combinePaths(currentDirectory, nodeModulesAtTypes)];
  | ➤ YN0000: │           }
  | ➤ YN0028: │ -         var typeRoots;
  | ➤ YN0028: │ +         var typeRoots = [];
  | ➤ YN0000: │           ts.forEachAncestorDirectory(ts.normalizePath(currentDirectory), function (directory) {
  | ➤ YN0000: │               var atTypes = ts.combinePaths(directory, nodeModulesAtTypes);
  | ➤ YN0000: │               if (host.directoryExists(atTypes)) {
  | ➤ YN0028: │ -                 (typeRoots \|\| (typeRoots = [])).push(atTypes);
  | ➤ YN0028: │ +                 typeRoots.push(atTypes);
  | ➤ YN0000: │               }
  | ➤ YN0000: │               return undefined;
  | ➤ YN0000: │           });
  | ➤ YN0000: │           return typeRoots;
  | ➤ YN0000: │       }
  | ➤ YN0000: │       var nodeModulesAtTypes = ts.combinePaths("node_modules", "@types");
  | ➤ YN0028: │ +     function getPnpTypeRoots(currentDirectory) {
  | ➤ YN0028: │ +         var pnpapi = getPnpApi(currentDirectory);
  | ➤ YN0028: │ +         if (!pnpapi) {
  | ➤ YN0028: │ +             return [];
  | ➤ YN0028: │ +         }
  | ➤ YN0028: │ +         currentDirectory = ts.sys.resolvePath(currentDirectory);
  | ➤ YN0028: │ +         var currentPackage = pnpapi.findPackageLocator(currentDirectory + "/");
  | ➤ YN0028: │ +         if (!currentPackage) {
  | ➤ YN0028: │ +             return [];
  | ➤ YN0028: │ +         }
  | ➤ YN0028: │ +         var packageDependencies = pnpapi.getPackageInformation(currentPackage).packageDependencies;
  | ➤ YN0028: │ +         var typeRoots = [];
  | ➤ YN0028: │ +         for (var _i = 0, _a = Array.from(packageDependencies.entries()); _i < _a.length; _i++) {
  | ➤ YN0028: │ +             var _b = _a[_i], name = _b[0], referencish = _b[1];
  | ➤ YN0028: │ +             if (name.startsWith(typesPackagePrefix) && referencish !== null) {
  | ➤ YN0028: │ +                 var dependencyLocator = pnpapi.getLocator(name, referencish);
  | ➤ YN0028: │ +                 var packageLocation = pnpapi.getPackageInformation(dependencyLocator).packageLocation;
  | ➤ YN0028: │ +                 typeRoots.push(ts.getDirectoryPath(packageLocation));
  | ➤ YN0028: │ +             }
  | ➤ YN0028: │ +         }
  | ➤ YN0028: │ +         return typeRoots;
  | ➤ YN0028: │ +     }
  | ➤ YN0028: │ +     ts.getPnpTypeRoots = getPnpTypeRoots;
  | ➤ YN0028: │ +     var typesPackagePrefix = "@types/";
  | ➤ YN0028: │ +     function getDefaultTypeRoots(currentDirectory, host) {
  | ➤ YN0028: │ +         var nmTypes = getNodeModulesTypeRoots(currentDirectory, host);
  | ➤ YN0028: │ +         var pnpTypes = getPnpTypeRoots(currentDirectory);
  | ➤ YN0028: │ +         if (nmTypes.length > 0 \|\| pnpTypes.length > 0) {
  | ➤ YN0028: │ +             return __spreadArray(__spreadArray([], nmTypes, true), pnpTypes, true);
  | ➤ YN0028: │ +         }
  | ➤ YN0028: │ +     }
  | ➤ YN0000: │       function resolveTypeReferenceDirective(typeReferenceDirectiveName, containingFile, options, host, redirectedReference, cache) {
  | ➤ YN0000: │           var traceEnabled = isTraceEnabled(options, host);
  | ➤ YN0000: │           if (redirectedReference) {

We have a resolution entry for typescript, so we only have the 1 version.

milesj · 2022-03-18T22:01:34Z

@arcanis @merceyz Tried another repo, same problem. Had teammates test patches and they report it also not patching, even locally.

So I created a simple repo as a test case and the patch still is not applied, even locally: https://github.com/milesj/yarn-patch-transient-deps We tried Yarn 3.2 and 3.1 and both failed.

This looks to be a legitimate bug in Yarn.

EDIT: Confirmed patching works for explicit deps (patch: in the version range), but not for transient deps OR explicit deps using resolutions:

Works:

  "devDependencies": {
    "@react-native-community/cli": "patch:@react-native-community/cli@npm:^6.4.0#../../.yarn/patches/@react-native-community-cli-npm-6.4.0-f99ee73e09",
  }

Does not work:

  "devDependencies": {
    "@react-native-community/cli": "^6.4.0"
  },
  "resolutions": {
    "@react-native-community/cli": "patch:@react-native-community/cli@npm:^6.4.0#../../.yarn/patches/@react-native-community-cli-npm-6.4.0-f99ee73e09",
  }

Also does not work (transitive dep):

  "resolutions": {
    "@react-native-community/cli": "patch:@react-native-community/cli@npm:^6.4.0#../../.yarn/patches/@react-native-community-cli-npm-6.4.0-f99ee73e09",
  }

arcanis · 2022-03-18T22:39:22Z

This particular problem is known (and fixed, once #4218 is merged). The resolutions syntax expects an exact match on the range compared to what the dependency truly is, but yarn patch-commit incorrectly sets a different range that generally doesn't match what the dependency actually is. For example in your example repo, @react-native-community/cli is depended upon by react-native which lists it with the range "^6.0.0" (not "6.4.0").

To fixes that, just replace:

"resolutions": {
  "@react-native-community/[email protected]": "patch:..."
}

By:

"resolutions": {
  "@react-native-community/cli@^6.0.0": "patch:..."
}

Another option is to remove the range altogether, in which case all instances of @react-native-community/cli will be patched (in your last message you said it doesn't work, but I suspect you made a mistaken copy-paste and forgot the range in your snippets, as I just tested it and it definitely works):

"resolutions": {
  "@react-native-community/cli": "patch:..."
}

milesj · 2022-03-19T05:20:42Z

That... makes sense in retrospect. Will give that a try again on Monday.

Although the PR is improving patches, it would be nice if Yarn would warn if there's a patch that doesn't get applied for some reason.

milesj · 2022-03-21T17:50:09Z

Tested and works 👍

Thanks for the info and reading my rambling.

imranbarbhuiya · 2022-07-10T10:37:00Z

This particular problem is known (and fixed, once #4218 is merged). The resolutions syntax expects an exact match on the range compared to what the dependency truly is, but yarn patch-commit incorrectly sets a different range that generally doesn't match what the dependency actually is. For example in your example repo, @react-native-community/cli is depended upon by react-native which lists it with the range "^6.0.0" (not "6.4.0").

To fixes that, just replace:
"resolutions": {
  "@react-native-community/[email protected]": "patch:..."
}
By:
"resolutions": {
  "@react-native-community/cli@^6.0.0": "patch:..."
}
Another option is to remove the range altogether, in which case all instances of @react-native-community/cli will be patched (in your last message you said it doesn't work, but I suspect you made a mistaken copy-paste and forgot the range in your snippets, as I just tested it and it definitely works):
"resolutions": {
  "@react-native-community/cli": "patch:..."
}

I'm still experiencing this issue and adding ^ manually works.

* chore: maybe we are now 100% browser compitible? * chore: why is everything broken permalink: http://whatthecommit.com/61392d8529ad51956024f721ebf30995 * chore: epic permalink: http://whatthecommit.com/d9796047a759e445935a287c17d1037c * chore: is there an award for this? permalink: http://whatthecommit.com/cb4f7f1124e8bd95fc10f272830701d3 * ci: push unfinished test * chore: merge pull my finger request permalink: http://whatthecommit.com/569aa58b98f6e4aac466357a4997c2b2 * ci: do in correct way * ci: fix scripts and build once * ci: skip lib check bcz of happy-dom typings * ci: change name * test: fix file path * chore: use jsdom * chore: it worked * ci: change test as vitest is weired * chore: remove script * chore: fix pc load letter error permalink: http://whatthecommit.com/43398194a4cdd602ab7456be8066106f * chore: reinventing the wheel. again. permalink: http://whatthecommit.com/b2b30ca13c6041aee39eecb2b3a47211 * chore: readd `node:` protocol with a patch * chore: it worked yarnpkg/berry#4231 Co-authored-by: Jeroen Claassens <[email protected]>

sorenhoyer · 2022-07-12T21:14:47Z

I also faced this issue today, can confirm that the ^ worked. It's quite a hard error to debug when using pnp, so I really hope it will get fixed soon, as I think many people will just give up before they come in here and realize how simple the fix is.

xenoterracide · 2022-08-05T08:26:38Z

@arcanis if mine is a duplicate of this, and this is closed, and mine happened today on the latest release, how can this be fixed/closed?

arcanis · 2022-08-05T08:37:54Z

Because it's in RCs for the next 4.x major, not in 3.x patches.

imranbarbhuiya · 2022-08-05T08:40:09Z

It's a bug fix so why it's not coming in 3x?

xenoterracide · 2022-08-05T08:50:15Z

Could this be Cherry picked back to 3.x please?

wojtekmaj · 2022-08-05T09:04:21Z

I'm still experiencing issues with my patch resolution on 4.0.0-rc.14.

These were the resolutions generated by patch-commit on 3.x:

"@rewardopl/[email protected]": "patch:@rewardopl/react-native-toast@npm:1.2.0::__archiveUrl=https%3A%2F%2Fnpm.pkg.github.com%2Fdownload%2F%40rewardopl%2Freact-native-toast%2F1.2.0%2F30fa3fff8cce2eaaaff35fbc218041161631fd35cf06375f76834d890cffc2bd#.yarn/patches/@rewardopl-react-native-toast-npm-1.2.0-723ae2f371",
"@rewardopl/[email protected]": "patch:@rewardopl/react-native-ui@npm:1.7.0::__archiveUrl=https%3A%2F%2Fnpm.pkg.github.com%2Fdownload%2F%40rewardopl%2Freact-native-ui%2F1.7.0%2Fe3c4f7ab023dac67d7ad2157fb6502a8cf46ac5f7f7b035f59f2c28c7a824264#.yarn/patches/@rewardopl-react-native-ui-npm-1.7.0-7602a18b2b",

Changing key to @rewardopl/react-native-toast continues to throw an error. Note: unscoped packages didn't have this problem even in 3.x.
Changing key to @rewardopl/react-native-toast@^1.2.0 does not throw Error: Patch locators must explicitly define their source anymore during install, but still doesn't apply the patch. No error or warning is visible during install.

Edit: As per #4711 (comment), this worked:

"@rewardopl/react-native-toast@^1.2.0": "patch:@rewardopl/react-native-toast@npm:^1.2.0#.yarn/patches/@rewardopl-react-native-toast-npm-1.2.0-723ae2f371",
"@rewardopl/react-native-ui@^1.7.0": "patch:@rewardopl/react-native-ui@npm:^1.7.0#.yarn/patches/@rewardopl-react-native-ui-npm-1.7.0-7602a18b2b",

milesj · 2022-08-05T17:26:49Z

Yes this is is still very annoying. Anytime we use patches, they don't work immediately, and we constantly have to tinker with the resolution version to get them working. A fix in a release would be much appreciated.

See yarnpkg/berry#4231 (comment)

ffxsam · 2022-08-23T16:51:57Z

When will this fix be released on the stable branch?

merceyz · 2022-08-25T08:44:54Z

When will this fix be released on the stable branch?

The fix has been released in v3.2.3

danguilherme · 2022-12-22T21:27:23Z

When will this fix be released on the stable branch?

The fix has been released in v3.2.3

I am using yarn v3.3.1 and it didn't work for me.

ps-leocxy · 2023-02-01T01:42:50Z

When will this fix be released on the stable branch?

The fix has been released in v3.2.3

I am using yarn v3.3.1 and it didn't work for me.

Same here...

ianmartorell · 2023-03-15T14:36:21Z

I'm on yarn 3.2.3 and was having this issue where the patches would only be applied on first install, but would not work on subsequent installs.

I fixed it by changing the resolutions added by yarn automatically from this:

"@expo/[email protected]": "patch:@expo/cli@npm%3A0.6.2#./.yarn/patches/@expo-cli-npm-0.6.2-c9460e7c0e.patch",
"@expo/cli@^0.6.2": "patch:@expo/cli@npm%3A0.6.2#./.yarn/patches/@expo-cli-npm-0.6.2-c9460e7c0e.patch",
"@expo/[email protected]": "patch:@expo/cli@npm%3A0.6.2#./.yarn/patches/@expo-cli-npm-0.6.2-c9460e7c0e.patch"

To this:

"@expo/cli": "patch:@expo/cli@npm:^0.6.2#./.yarn/patches/@expo-cli-npm-0.6.2-c9460e7c0e.patch",

Notice the unescaping of the colon after npm and the inclusion of the ^ before the version number.

Now the patch gets correctly applied every time!

jleach · 2023-06-14T21:30:10Z

I made the above change and found similar resolution higher up that was problematic in my case. Although for me the problem was it not applying all the patches, just some of them. Anyway, hope this helps...

"resolutions": {
    "@types/react": "17.0.2",
    "@types/react-dom": "17.0.2",
    "@aries-framework/core": "0.3.3",
  ...
    "@aries-framework/[email protected]": "patch:@aries-framework/core@npm:0.3.3#./.yarn/patches/@aries-framework-core-npm-0.3.3-dd6486de3d.patch",
  }

I had to remove "@aries-framework/core": "0.3.3", for mine to work.

odinho · 2023-12-05T10:02:17Z

<deleted>

We hadn't updated to yarn 4, so what I said was likely fixed ^_^ Did the upgrade now. 👍

movy · 2024-01-31T09:31:47Z

just encountered this with the most recent yarn 4.0.2. After fiddling with package resolutions the patch was applied on production, but still could not see it on staging CI, very weird. No error messages either.

Initial package.json:

    "@uppy/compressor": "patch:@uppy/compressor@npm%3A1.0.5#~/.yarn/patches/@uppy-compressor-npm-1.0.5-c6622da068.patch",

What worked:

    "@uppy/compressor": "patch:@uppy/compressor@npm:^1.0.5#../../../../.yarn/patches/@uppy-compressor-npm-1.0.5-c6622da068.patch",

(unescaped %3A to :, added ^ and changed path to relative)

yarn.lock:

"@uppy/compressor@npm:^1.0.5":
  version: 1.0.5
  resolution: "@uppy/compressor@npm:1.0.5"
  dependencies:
    "@transloadit/prettier-bytes": "npm:^0.0.9"
    "@uppy/utils": "npm:^5.5.2"
    compressorjs: "npm:^1.1.1"
    preact: "npm:^10.5.13"
    promise-queue: "npm:^2.2.5"
  peerDependencies:
    "@uppy/core": ^3.6.0
  checksum: bd550351845b5d75daaf7f9626dce2f49a4c9a51dd9e665e05b2748ae8fd4d4f83c5973ec7aed43df9eea5053264f9bec3e167a622228f038b7a6dd4d341e298
  languageName: node
  linkType: hard

"@uppy/compressor@patch:@uppy/compressor@npm:^1.0.5#../../../../.yarn/patches/@uppy-compressor-npm-1.0.5-c6622da068.patch::locator=vue%40workspace%3Afront%2Fweb_server%2Fwww%2F_vue":
  version: 1.0.5
  resolution: "@uppy/compressor@patch:@uppy/compressor@npm%3A1.0.5#../../../../.yarn/patches/@uppy-compressor-npm-1.0.5-c6622da068.patch::version=1.0.5&hash=58663d&locator=vue%40workspace%3Afront%2Fweb_server%2Fwww%2F_vue"
  dependencies:
    "@transloadit/prettier-bytes": "npm:^0.0.9"
    "@uppy/utils": "npm:^5.5.2"
    compressorjs: "npm:^1.1.1"
    preact: "npm:^10.5.13"
    promise-queue: "npm:^2.2.5"
  peerDependencies:
    "@uppy/core": ^3.6.0
  checksum: a79efe83d7bf503551f5d293569d094438d7b62cb7941624687f9100a240936debf5a84016c8348f2e8e8f1db66da8d8b17628a22ee349910bdfae5b9fef3075
  languageName: node
  linkType: hard

gozegotushar · 2024-09-09T08:40:56Z

i was also facing problem with yarn : 3.6.4
yarn install was not successful, for other team mates yarn install was working fine.

solution used :

removed ~/ before yarn path.
c48c867a2c91)

getting issue with : "react-native-root-toast": "patch:react-native-root-toast@npm%3A3.5.1#~/.yarn/patches/react-native-root-toast-npm-3.5.1-f04b46d674.patch",
issue fixed : "react-native-root-toast": "patch:react-native-root-toast@npm%3A3.5.1#.yarn/patches/react-native-root-toast-npm-3.5.1-f04b46d674.patch",

used locator with upgraded patch. ( resident_app is project name )

getting issue with : "react-native-snap-carousel": "patch:react-native-snap-carousel@patch%3Areact-native-snap-carousel@npm%253A3.9.1%23~/.yarn/patches/react-native-snap-carousel-npm-3.9.1-14bebfe4a7.patch%3A%3Aversion=3.9.1&hash=25be1a#~/.yarn/patches/react-native-snap-carousel-patch-c304848e43.patch",
issue fixed : "react-native-snap-carousel": "patch:react-native-snap-carousel@patch%3Areact-native-snap-carousel@npm%253A3.9.1%23.yarn/patches/react-native-snap-carousel-npm-3.9.1-14bebfe4a7.patch%3A%3Aversion=3.9.1&hash=25be1a&locator=resident_app%2540workspace%253A.#.yarn/patches/react-native-snap-carousel-patch-c304848e43.patch"

milesj added the bug Something isn't working label Mar 16, 2022

milesj changed the title ~~[Bug]: Yarn patches are not applied when node modules are loaded from a cache~~ [Bug]: Yarn patches are not applied in CI Mar 18, 2022

milesj changed the title ~~[Bug]: Yarn patches are not applied in CI~~ [Bug]: Yarn patches are not applied for transient deps using resolutions Mar 18, 2022

milesj changed the title ~~[Bug]: Yarn patches are not applied for transient deps using resolutions~~ [Bug]: Yarn patches are not applied for deps using resolutions Mar 18, 2022

arcanis added the waiting for feedback Will autoclose in a while unless more data are provided label Mar 18, 2022

milesj closed this as completed Mar 21, 2022

svvac mentioned this issue Jul 27, 2022

Missing regexTypes.d.ts in distributed module sql-formatter-org/sql-formatter#353

Closed

lachlanhunt mentioned this issue Aug 5, 2022

[Bug?]: yarn patch generated unparsable patch: URL #4711

Open

1 task

xenoterracide mentioned this issue Aug 5, 2022

[Bug?]: patch constructs completely wrong resolutions section #4712

Closed

1 task

Zeta611 added a commit to Zeta611/easyword that referenced this issue Aug 15, 2022

🐛 Fix Netlify build issue once and for all?

d9b0582

See yarnpkg/berry#4231 (comment)

kachkaev mentioned this issue Oct 8, 2022

[Feature] Peer dependency resolutions #4099

Open

2 tasks

rin-st mentioned this issue May 30, 2023

Patch useLocalStorage setting the right initial value to avoid a hydration error scaffold-eth/scaffold-eth-2#356

Merged

matteolucinip mentioned this issue Jan 8, 2024

Error installing boost Verification checksum was incorrect boostorg/boost#843

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[Bug]: Yarn patches are not applied for deps using `resolutions` #4231

[Bug]: Yarn patches are not applied for deps using `resolutions` #4231

milesj commented Mar 16, 2022 •

edited

Loading

merceyz commented Mar 16, 2022 •

edited

Loading

milesj commented Mar 16, 2022

milesj commented Mar 18, 2022

milesj commented Mar 18, 2022 •

edited

Loading

milesj commented Mar 18, 2022

milesj commented Mar 18, 2022

milesj commented Mar 18, 2022 •

edited

Loading

arcanis commented Mar 18, 2022

milesj commented Mar 18, 2022

milesj commented Mar 18, 2022

milesj commented Mar 18, 2022 •

edited

Loading

arcanis commented Mar 18, 2022

milesj commented Mar 19, 2022

milesj commented Mar 21, 2022

imranbarbhuiya commented Jul 10, 2022

sorenhoyer commented Jul 12, 2022

xenoterracide commented Aug 5, 2022

arcanis commented Aug 5, 2022

imranbarbhuiya commented Aug 5, 2022

xenoterracide commented Aug 5, 2022

wojtekmaj commented Aug 5, 2022 •

edited

Loading

milesj commented Aug 5, 2022

ffxsam commented Aug 23, 2022 •

edited

Loading

merceyz commented Aug 25, 2022

danguilherme commented Dec 22, 2022

ps-leocxy commented Feb 1, 2023

ianmartorell commented Mar 15, 2023

jleach commented Jun 14, 2023

odinho commented Dec 5, 2023 •

edited

Loading

movy commented Jan 31, 2024 •

edited

Loading

gozegotushar commented Sep 9, 2024 •

edited

Loading

[Bug]: Yarn patches are not applied for deps using resolutions #4231

[Bug]: Yarn patches are not applied for deps using resolutions #4231

Comments

milesj commented Mar 16, 2022 • edited Loading

Self-service

Describe the bug

To reproduce

Environment

Additional context

merceyz commented Mar 16, 2022 • edited Loading

milesj commented Mar 16, 2022

milesj commented Mar 18, 2022

milesj commented Mar 18, 2022 • edited Loading

milesj commented Mar 18, 2022

milesj commented Mar 18, 2022

milesj commented Mar 18, 2022 • edited Loading

arcanis commented Mar 18, 2022

milesj commented Mar 18, 2022

milesj commented Mar 18, 2022

milesj commented Mar 18, 2022 • edited Loading

arcanis commented Mar 18, 2022

milesj commented Mar 19, 2022

milesj commented Mar 21, 2022

imranbarbhuiya commented Jul 10, 2022

sorenhoyer commented Jul 12, 2022

xenoterracide commented Aug 5, 2022

arcanis commented Aug 5, 2022

imranbarbhuiya commented Aug 5, 2022

xenoterracide commented Aug 5, 2022

wojtekmaj commented Aug 5, 2022 • edited Loading

milesj commented Aug 5, 2022

ffxsam commented Aug 23, 2022 • edited Loading

merceyz commented Aug 25, 2022

danguilherme commented Dec 22, 2022

ps-leocxy commented Feb 1, 2023

ianmartorell commented Mar 15, 2023

jleach commented Jun 14, 2023

odinho commented Dec 5, 2023 • edited Loading

movy commented Jan 31, 2024 • edited Loading

gozegotushar commented Sep 9, 2024 • edited Loading

i was also facing problem with yarn : 3.6.4 yarn install was not successful, for other team mates yarn install was working fine.

[Bug]: Yarn patches are not applied for deps using `resolutions` #4231

[Bug]: Yarn patches are not applied for deps using `resolutions` #4231

milesj commented Mar 16, 2022 •

edited

Loading

merceyz commented Mar 16, 2022 •

edited

Loading

milesj commented Mar 18, 2022 •

edited

Loading

milesj commented Mar 18, 2022 •

edited

Loading

milesj commented Mar 18, 2022 •

edited

Loading

wojtekmaj commented Aug 5, 2022 •

edited

Loading

ffxsam commented Aug 23, 2022 •

edited

Loading

odinho commented Dec 5, 2023 •

edited

Loading

movy commented Jan 31, 2024 •

edited

Loading

gozegotushar commented Sep 9, 2024 •

edited

Loading

i was also facing problem with yarn : 3.6.4
yarn install was not successful, for other team mates yarn install was working fine.