Yarn: Deterministic install with multiple version of same package

[jonaskello]

Sorry if this is the wrong place to ask or if it has been covered before but I could not find any information about this. I am curious about the deterministic nature of yarn install when it has to choose between multiple versions of the same package.

From what I gather the idea is that using the same yarn.lock file will repeatedly create the same node_modules structure. The exact versions of all packages are found in the yarn.lock file so understanding which versions to install is easy.

But if we depend on four packages that depend on the same package but different versions, what version should get installed at the top level?

For example, given this package.json:

{
  "name": "yarn-multiple",
  "version": "1.0.0",
  "main": "index.js",
  "license": "MIT",
  "dependencies": {
    "stylus-unit": "0.0.4",
    "react-dom-utils": "2.0.0",
    "naf": "0.0.1",
    "thick": "0.0.6"
  }
}

Here all four of our dependencies depend on lodash but different major versions:

thick0.0.6 -> lodash@~1.0.1
[email protected] -> lodash@~2.4.1
[email protected] -> lodash@^3.10.1
[email protected] -> lodash@^4.6.1

What version of lodash gets installed at the top level in this scenario and is there any algorithm that makes this decision deterministic using the yarn.lock file?

Here is the result I get but I don't understand why [email protected] is choosen for the top-level install:

$ yarn --version
0.19.0-20161204.1900
$ yarn install
$ cat node_modules/lodash/package.json | grep version
  "version": "3.10.1",

[brandondurham]

Any information ever shared around this question?

[shai32]

can someone please answer?

[rc-davis]

I'd like to know, too.

[alexanderkartavtsev]

+1

[timaschew]

For me, I'm using yarn 0.23.2 (0.23.4 is the latest btw) lodash 4.17.4 is installed at top level.

$ find . -regex '.*/lodash/package*.json'
./node_modules/lodash/package.json
./node_modules/naf/node_modules/lodash/package.json
./node_modules/stylus-unit/node_modules/lodash/package.json
./node_modules/thick/node_modules/lodash/package.json

$ find . -regex '.*/lodash/package*.json' | xargs cat | grep version
  "version": "4.17.4",
  "version": "2.4.2",
  "version": "3.10.1",
  "version": "1.0.2",

So either it was a bug that leads to install lodash 3 in earlier versions of yarn or maybe the usage of lodash has changed and it will pickup the most used version to install at top level.
In my case version 4 was used in two libraries logs and react-dom-utils.

Snippets of my _yarn.lock_ file:

logs@latest:
  version "1.1.2"
  resolved "https://artifactory.in.here.com/artifactory/api/npm/here-node/logs/-/logs-1.1.2.tgz#58bd484a7c87ed9349a7b12f62b6a783254ef889"
  dependencies:
    chalk "^1.1.3"
    dateformat "^1.0.12"
    inflection "^1.10.0"
    lodash "^4.17.2"
    stack-trace "0.0.9"

[email protected]:
  version "2.0.0"
  resolved "https://artifactory.in.here.com/artifactory/api/npm/here-node/react-dom-utils/-/react-dom-utils-2.0.0.tgz#757c074b300000da5b0990b637b7eea36f0bc5e4"
  dependencies:
    element-resize-detector "^1.1.0"
    lodash "^4.6.1"

Since you didn't provide any _yarn.lock_ file that is hard to say, because the module logs maybe upgraded their lodash version in the meantime. More specific: a dependency of naf are using latest version of logs

[email protected]:
  version "0.0.1"
  resolved "https://artifactory.in.here.com/artifactory/api/npm/here-node/naf/-/naf-0.0.1.tgz#71d2e24e4540dcd056a352577d115a574b45d9b4"
  dependencies:
    eventemitter2 "~0.4.13"
    lodash "~2.4.1"
    logs latest
    yaml-js latest

So even with the same package.json the dependency tree could change from one second to the next if logs publish their new version with upgraded dependencies.

[BYK]

Closing since this doesn't seem to be an issue in the latest versions.

[jonaskello]

Actually this was never meant as an issue that could be fixed in a later version :-). It was just a question about how the deterministic algoritm in yarn works when it has to choose between multiple versions of the same package. I still have not seen that described anywhere.

[jtheisen]

This should be reopened and closed once it's documented in the manual.

It should also be clarified if subsequent yarn runs will always produce the same structure as fresh runs (those without a pre-existing node_modules tree) do.