Yarn: Warning: pattern is trying to unpack in the same destination

[julien-f]

Do you want to request a feature or report a bug?

bug

What is the current behavior?

warning Pattern ["@babel/core@^7.0.0-beta.5"] is trying to unpack in the same destination "/home/bob/.cache/yarn/v1/npm-@babel/core-7.0.0-beta.5-b00f480c4992aa7cf6fce18819b4f1e9ffaec556" as pattern ["@babel/[email protected]"]. This could result in a non deterministic behavior, skipping.

If the current behavior is a bug, please provide the steps to reproduce.

mkdir test-project
cd test-project
yarn add -D @babel/[email protected]
yarn add -D @babel/[email protected]

What is the expected behavior?

No warning.

Please mention your node.js, yarn and operating system version.

Fedora 26 (Workstation Edition)

yarn versions v1.2.1
{ http_parser: '2.7.0',
  node: '8.8.1',
  v8: '6.1.534.42',
  uv: '1.15.0',
  zlib: '1.2.11',
  ares: '1.10.1-DEV',
  modules: '57',
  nghttp2: '1.25.0',
  openssl: '1.0.2l',
  icu: '59.1',
  unicode: '9.0',
  cldr: '31.0.1',
  tz: '2017b' }

[gcardacci]

I'm getting a similar error. Related to esprima-fb.
Does anyone know any solution for this?

[pmowrer]

I'm running into this when trying to use yarn workspaces

[also]

I encountered a similar error:

warning Pattern ["strip-bom-stream@^2.0.0"] is trying to unpack in the same destination "/Users/rberdeen/Library/Caches/Yarn/v1/npm-strip-bom-2.0.0-f87db5ef2613f6968aa545abfe1ec728b6a829ca" as pattern ["strip-bom@^2.0.0"]. This could result in a non deterministic behavior, skipping.

This seems to be an issue with yarn install incorrectly resolving merge conflicts in yarn.lock. In my case, two different packages ended up pointing at the same thing.
With this merge conflict:

++<<<<<<< HEAD
 +strip-bom-stream@^2.0.0:
++=======
[email protected], strip-bom@^3.0.0:
++  version "3.0.0"
++  resolved "https://example.com/strip-bom/-/strip-bom-3.0.0.tgz#2334c18e9c759f7bdd56fdef7e9ae3d588e68ed3"
++
++strip-bom@^2.0.0:
++>>>>>>> origin/master
 +  version "2.0.0"
 +  resolved "https://example.com/strip-bom-stream/-/strip-bom-stream-2.0.0.tgz#f87db5ef2613f6968aa545abfe1ec728b6a829ca"
 +  dependencies:
 +    first-chunk-stream "^2.0.0"
 +    strip-bom "^2.0.0"
 +
++<<<<<<< HEAD
  [email protected], strip-bom@^3.0.0:
    version "3.0.0"
    resolved "https://example.com/strip-bom/-/strip-bom-3.0.0.tgz#2334c18e9c759f7bdd56fdef7e9ae3d588e68ed3"
@@@ -8649,6 -3978,6 +9384,8 @@@ strip-bom@^2.0.0
    dependencies:
      is-utf8 "^0.2.0"

++=======
++>>>>>>> origin/master

Yarn resolved the conflicts

$ yarn
yarn install v1.3.2
info Merge conflict detected in yarn.lock and successfully merged.

into a lockfile that doesn't work:

- strip-bom-stream@^2.0.0:
++strip-bom-stream@^2.0.0, strip-bom@^2.0.0:
 +  version "2.0.0"
 +  resolved "https://example.com/strip-bom-stream/-/strip-bom-stream-2.0.0.tgz#f87db5ef2613f6968aa545abfe1ec728b6a829ca"
 +  dependencies:
 +    first-chunk-stream "^2.0.0"
 +    strip-bom "^2.0.0"
 +
  [email protected], strip-bom@^3.0.0:
    version "3.0.0"
    resolved "https://example.com/strip-bom/-/strip-bom-3.0.0.tgz#2334c18e9c759f7bdd56fdef7e9ae3d588e68ed3"

--strip-bom@^2.0.0:
--  version "2.0.0"
--  resolved "https://example.com/strip-bom/-/strip-bom-2.0.0.tgz#6219a85616520491f35788bdbf1447a99c7e6b0e"
--  dependencies:
--    is-utf8 "^0.2.0"
--

My issue seems to be the same as #4737

[nemoDreamer]

THANK YOU @also !!

This seems to be an issue with yarn install incorrectly resolving merge conflicts in yarn.lock. In my case, two different packages ended up pointing at the same thing.

I had been getting a lot of merge conflicts, and saw that when I simply yarn install, it would show "Resolved conflicts". I trusted that that would be ok...

Now, I do git checkout --theirs yarn.lock before running yarn install, since it seems its auto-resolution is a bit wonky.

[jeff-kilbride]

Also happens when simply adding babel-runtime. I first did this:

$ yarn add -D babel-core babel-loader babel-plugin-transform-runtime babel-preset-env babel-preset-stage-3 serverless-webpack webpack webpack-node-externals

which was fine. Then added babel-runtime and got this:

$ yarn add babel-runtime
yarn add v1.5.1
[1/4] 🔍  Resolving packages...
[2/4] 🚚  Fetching packages...
warning Pattern ["babel-runtime@^6.26.0","babel-runtime@^6.26.0","babel-runtime@^6.22.0","babel-runtime@^6.22.0","babel-runtime@^6.26.0","babel-runtime@^6.26.0","babel-runtime@^6.26.0","babel-runtime@^6.26.0","babel-runtime@^6.22.0","babel-runtime@^6.22.0","babel-runtime@^6.22.0","babel-runtime@^6.22.0","babel-runtime@^6.22.0","babel-runtime@^6.26.0","babel-runtime@^6.22.0","babel-runtime@^6.22.0","babel-runtime@^6.22.0","babel-runtime@^6.22.0","babel-runtime@^6.22.0","babel-runtime@^6.22.0","babel-runtime@^6.22.0","babel-runtime@^6.22.0","babel-runtime@^6.26.0","babel-runtime@^6.22.0","babel-runtime@^6.22.0","babel-runtime@^6.22.0","babel-runtime@^6.22.0","babel-runtime@^6.22.0","babel-runtime@^6.22.0","babel-runtime@^6.22.0","babel-runtime@^6.22.0","babel-runtime@^6.22.0","babel-runtime@^6.22.0","babel-runtime@^6.22.0","babel-runtime@^6.22.0","babel-runtime@^6.26.0","babel-runtime@^6.22.0","babel-runtime@^6.22.0","babel-runtime@^6.22.0","babel-runtime@^6.22.0","babel-runtime@^6.22.0","babel-runtime@^6.22.0","babel-runtime@^6.22.0","babel-runtime@^6.26.0","babel-runtime@^6.22.0","babel-runtime@^6.18.0","babel-runtime@^6.22.0","babel-runtime@^6.22.0","babel-runtime@^6.26.0"] is trying to unpack in the same destination "/Users/jeff/Library/Caches/Yarn/v1/npm-babel-runtime-6.26.0-965c7058668e82b55d7bfe04ff2337bc8b5647fe" as pattern ["babel-runtime@^6.26.0"]. This could result in non-deterministic behavior, skipping.
[3/4] 🔗  Linking dependencies...
[4/4] 📃  Building fresh packages...
success Saved 1 new dependency.
info Direct dependencies
└─ [email protected]
info All dependencies
└─ [email protected]
✨  Done in 2.48s.

I think it installed correctly, but the warning is fairly menacing. This is on MacOS 10.12.6, Node v8.10.0.

[RaulTsc]

Getting this warning when doing yarn install but everything seems to work fine.

warning Pattern ["esprima-fb@~3001.0001.0000-dev-harmony-fb"] is trying to unpack in the same destination "/Users/raul/Library/Caches/Yarn/v1/npm-esprima-fb-3001.1.0-dev-harmony-fb-b77d37abcd38ea0b77426bb8bc2922ce6b426411" as pattern ["esprima-fb@~3001.1.0-dev-harmony-fb"]. This could result in a non deterministic behavior, skipping.

[ntnyq]

Got this warning when initialize a react-native project with react-native-cli.

Adding Jest...
yarn add v1.6.0
[1/4] 🔍  Resolving packages...
[2/4] 🚚  Fetching packages...
warning Pattern ["[email protected]"] is trying to unpack in the same destination "/Users/ntnyq/Library/Caches/Yarn/v1/npm-babel-preset-react-native-4.0.0-3df80dd33a453888cdd33bdb87224d17a5d73959" as pattern ["babel-preset-react-native@^4.0.0"]. This could result in non-deterministic behavior, skipping.
[#####################################################################] 814/815 Pattern ["[email protected]"] is trying to unpack in the same dest[3/4] 🔗  Linking dependencies...
warning "react-native > [email protected]" has unmet peer dependency "eslint@^3.17.0 || ^4.0.0".
warning " > [email protected]" has unmet peer dependency "babel-core@^6.0.0 || ^7.0.0-0".
warning " > [email protected]" has unmet peer dependency "babel-core@^6.0.0 || ^7.0.0-0".
[4/4] 📃  Building fresh packages...
success Saved lockfile.
success Saved 132 new dependencies.

And the app works fine.

This is on Mac OS 10.13.4, Node v8.9.4, react-native-cli v2.0.1.

[JacopKane]

I have a workspace/monorepo with multiple packages depending on a @sub/package which also linked to root (by having "@sub/package-name": link:./@sub/package-path to make sure it'll be available in root if it'll not get somehow hoisted), and this is also linked by lerna to other sub packages.

While probably they are getting hoisted and cached I had this warning due to link path conflict.
PS: (interestingly I didn't have this warning on [email protected].* version).

Then I added:

"resolutions": {
    "**/@sub/package-name": "link:./@sub/package-path",
  },

to the root package.json and the warning is gone 🤷‍♂️

Although not sure if this will cause some errors in long-term yet.

PS: Unlike the main issue that is created, I didn't have any issues with external packages like react or @babel/core though.

[randak]

I had the same issue happen which matched @also's description of the problem. I ran yarn to resolve a merge conflict, and it combined multiple unrelated packages into a single entry in the yarn.lock. This caused a couple packages to throw this error. I was able to resolve the issue by just deleting that entry from my yarn.lock and re-running yarn.

[hossameldeen]

Same error. Steps:

• Had run yarn add uuid in several projects at different times, thus installing different versions.
• Ran yarn add uuid --exact in a project I didn't add uuid to before and got:

warning Pattern ["[email protected]"] is trying to unpack in the same destination "<home>/.cache/yarn/v4/npm-uuid-3.3.2-1b4af4955eb3077c501c23872fc6513811587131/node_modules/uuid" as pattern ["uuid@^3.3.2","uuid@^3.3.2","uuid@^3.0.1"]. This could result in non-deterministic behavior, skipping.

[gcardacci]

This problem has been solved in my project since I update my dependencies.
Current dependencies:

• "@babel/core": "^7.2.2",
• "@babel/preset-env": "^7.3.1",
• "@babel/preset-react": "^7.0.0",
• "webpack": "^4.29.2",
• "webpack-cli": "^3.2.3",
• "webpack-dev-server": "^3.1.14",

node version: 8.10.0
(With version 10.5.1 it also works correctly)

[Wayne-Shen]

Same error when try to global add aws-sdk

yarn global add aws-sdk

warning Pattern ["aws-sdk@^2.407.0"] is trying to unpack in the same destination "~/Caches/Yarn/v4/npm-aws-sdk-2.407.0-667d7f847e7f9b34cf57fa5e7c70e5f12637f72b/node_modules/aws-sdk" as pattern ["aws-sdk@^2.373.0"]. This could result in non-deterministic behavior, skipping.

[tboulis]

Any update on this? I have latest create-react-app and when trying to add prop-types I get the same error

[bbugh]

I've been seeing this on my large production app for a while, but I just got it again with a brand new project, with this exact command sequence:

yarn init -y -p
yarn add -D typescript

warning Pattern ["typescript@^3.4.3"] is trying to unpack in the same destination "/Users/bbugh/Library/Caches/Yarn/v4/npm-typescript-3.4.3-0eb320e4ace9b10eadf5bc6103286b0f8b7c224f/node_modules/typescript" as pattern ["typescript@^3.3.3"]. This could result in non-deterministic behavior, skipping.

[giorgio-zamparelli]

SOLVED:
I was seeing a similar error with esprima-fb version 3001.1.0-dev-harmony-fb.
I found out esprima-fb was a sub-sub-dependency of [email protected]
I updated localforage to 1.5.7 and the yarn warning disappeared.
In case yarn list esprima-fb is not working you can look in the yarn.lock to find the root dipendency that is using esprima-fb version 3001.1.0-dev-harmony-fb

[jeffrson]

Here's another example - don't know if it's necessary due to the lack of response.

Given this simplest package.json:

{
  "name": "test",
  "version": "0.1.0"
}

Now execute yarn add eslint (which adds a dependency to "^6.3.0" at the time of writing, so yarn add eslint@^6.3.0 would suffice later as well), followed by yarn add debug. Which results in

warning Pattern ["debug@^4.1.1"] is trying to unpack in the same destination "C:\...\Yarn\Cache\v4\npm-debug-4.1.1-3b72260255109c6b589cee050f1d516139664791\node_modules\debug" as pattern ["debug@^4.0.1"]. This could result in non-deterministic behavior, skipping.

The problem seems AFAICT, that eslint depends on debug@^4.0.1, which is actually resolved by 4.1.1. Here's the part of yarn.lock;

debug@^4.0.1:
  version "4.1.1"
  resolved "https://registry.yarnpkg.com/debug/-/debug-4.1.1.tgz#3b72260255109c6b589cee050f1d516139664791"
  integrity sha512-pYAIzeRo8J6KPEaJ0VWOh5Pzkbw/RetuzehGM7QRRX5he4fPHx2rdKMB256ehJCkX+XRQm16eZLqLNS8RSZXZw==
  dependencies:
    ms "^2.1.1"

eslint@^6.3.0:
  version "6.3.0"
  resolved "https://registry.yarnpkg.com/eslint/-/eslint-6.3.0.tgz#1f1a902f67bfd4c354e7288b81e40654d927eb6a"
  integrity sha512-ZvZTKaqDue+N8Y9g0kp6UPZtS4FSY3qARxBs7p4f0H0iof381XHduqVerFWtK8DPtKmemqbqCFENWSQgPR/Gow==
  dependencies:
...
    debug "^4.0.1"
...

It seems that this subdependency is not correctly resolved when adding the debug package (latest version currently being 4.1.1)

Any chance to get this fixed? It's rather irritating.

[richburdon]

Also breaking for me.

[kirandash]

I too am getting the same issue. Any one has managed to fix this?

yarn install
yarn install v1.16.0
[1/4] Resolving packages...
[2/4] Fetching packages...
warning Pattern ["operation-retrier@latest"] is trying to unpack in the same destination "/home/truuue/.cache/yarn/v4/npm-operation-retrier-2.0.0-5d47178f2a05f24ae65fc2413e78cd8e50a575fa/node_modules/operation-retrier" as pattern ["operation-retrier@^2.0.0","operation-retrier@^2.0.0","operation-retrier@^2.0.0","operation-retrier@^2.0.0"]. This could result in non-deterministic behavior, skipping.
error Command failed.
Exit code: 128
Command: git
Arguments: ls-remote --tags --heads https://github.com/Kahuna/kahuna-marketplaces-reactnative.git
Directory: /home/truuue/Desktop/truuue-tenant/latest/truuue-tenant-app
Output:
fatal: could not read Username for 'https://github.com': terminal prompts disabled
info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this command.

[hankthewhale]

So for my case, we use npm aliases to manage two versions of various packages, specifically react-router 3 and react router 4. This also means that we manage two versions of history.

This resulted in Warning: pattern is trying to unpack in the same destination. Skipping. So not a failure, but it certainly caused issues since the version that we were attempting to install of history was being ignored.

To "solve" our issue, I manually went into the yarn.lock file and changed the version of the history dependency for react-router@3 to match the one specified in our package.json. This obviously isn't ideal and is likely not to solve the issue for the others in here, but wanted to bring back my observations just in case it does help someone.

[Nvveen]

2.5 years later, and still nothing.

[hankthewhale]

@Nvveen you can try using yarn resolutions. https://classic.yarnpkg.com/en/docs/selective-version-resolutions/

Like I said above, I solved the issue initially by doing it manually but I ended up using resolutions to fix it for realsies.

Shortly after, the issue was resolved entirely since our team ended up using workspaces to organize our modules. Part of our issue was due to supporting a legacy version of our codebase while also building a v2 that shared the same modules. This led to two different versions of react router attempting to use the same version of history.

Anyway, hopefully you find luck with yarn resolutions.

[Luxcium]

I was getting warningPattern ["tslib@^1.11.1"] is trying to unpack in the same destination "/Users/luxcium/Library/Caches/Yarn/v6/npm-tslib-1.11.1-eb15d128827fbee2841549e171f45ed338ac7e35-integrity/node_modules/tslib" as pattern ["tslib@^1.8.1","tslib@^1.9.0","tslib@^1.10.0"]. This could result in non-deterministic behavior, skipping.

But thank to @hankthewhale I don't have the warning anymore !!!

https://classic.yarnpkg.com/en/docs/selective-version-resolutions/

Edit

It is the third time I end up here to find a solution for this problem...

but just in the hope to help google direct me to yarnpkg.com web site next time I decided to post the link as part of the problem (bug) description:
_warning:_ Pattern["PATTERN@^2.43.15"]is trying to unpack in the same destination "/[home]/.cache/yarn/v6/npm-PATTERN-2.43.15-[sha-checksum]-integrity/node_modules/PATTERN"as pattern["PATTERN@^2.41.13-OTHER_version"]This could result in non-deterministic behavior, _skipping_

Selective version resolutions

The solution is not perfect but it's called _Selective version resolutions_

Here what they say on _yarnpkg.com_:

How to use it

Add a resolutions field to your package.json file and define your version overrides then run yarn install.

{
  "name": "project",
  "version": "1.0.0",
  "dependencies": {
    "left-pad": "1.0.0",
    "c": "file:../c-1",
    "d2": "file:../d2-1"
  },
  "resolutions": {
    "d2/left-pad": "1.1.1",
    "c/**/left-pad": "^1.1.2"
  }
}

[adamcaron]

This worked:

yarn add prop-types@^15.7.2

Previously, when running:

yarn add prop-types

...the result was:

warning Pattern ["prop-types@^15.7.2"] is trying to unpack in the same destination "/Users/adamcaron/Library/Caches/Yarn/v6/npm-prop-types-15.7.2-52c41e75b8c87e72b9d9360e0206b99dcbffa6c5-integrity/node_modules/prop-types" as pattern ["prop-types@^15.6.2","prop-types@^15.6.2","prop-types@^15.7.2","prop-types@^15.7.2","prop-types@^15.7.2","prop-types@^15.7.2","prop-types@^15.6.2","prop-types@^15.7.2","prop-types@^15.7.2"]. This could result in non-deterministic behavior, skipping.

Using...

• create-react-app 3.4.1
• node v12.18.3
• yarn 1.22.4
• macOS 10.14.6

Hopefully it helps someone