Posted in Uncategorized

yarn.lock changes, even though it was just generated

   February 24, 2021  5 Comments on yarn.lock changes, even though it was just generated

@arcanis this started happening fairly recently. I’m not sure if this is a regression due to 1.21.1, or the new fsevents release (or something else entirely).

Do you want to request a feature or report a bug?
Bug. Probably affecting many out there.

What is the current behavior?
yarn changes yarn.lock after a secondary run.

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

https://github.com/wixplosives/sample-monorepo

git clone git@github.com:wixplosives/sample-monorepo.git
cd sample-monorepo
rm yarn.lock
yarn # generates a fresh new yarn.lock file
rm -rf node_modules # important, otherwise bug doesn't happen
git add yarn.lock # to be able to see whether lock file changed
yarn
git status
# bug is here. "modified:   yarn.lock"

What is the expected behavior?
A fresh install of yarn should generate a “final” lock file. Running yarn on the generated yarn.lock should not change it unless a version request was changed (someone modified package.json since lock file generation).

Please mention your node.js, yarn and operating system version.
yarn 1.21.1
node 12.13.1
fedora 31

Observations
fsevents released a new node12 compatible version (v1.2.11). yarn picks that version up. it’s an optional dependency of chokidar. older versions of fsevents had node-pre-gyp as a dependency, and that seems to be the major change in the lock file. not sure if it’s related, but perhaps you’ll know more. Should be noted that fsevents does not end up installed (optional dep) on non-darwin machines, such as my linux machine.

Author: Fantashit

5 thoughts on “yarn.lock changes, even though it was just generated”

  1. That’s the same issue.
    I have a bit different observation to: “it will stay in yarn.lock no matter how many times I run yarn”

    As noted in the steps to reproduce, if I manually remove node_modules and then execute yarn, it will remove node-pre-gyp.

  3. Did a bit of research, and just dropping some notes:

    You can reproduce this issue with the very simple non-workspace package.json

    {
  "name": "sample",
  "devDependencies": {
    "fsevents": "1.2.11"
  }
}

    Then

    yarn install
git commit -am "initial"
yarn install --force

    at this point yarn.lock will be different.

    It looks like fsevents includes a bundledDependency

      "bundledDependencies": [
    "node-pre-gyp"
  ],

    and on the initial clean install, node-pre-gyp is added to the lockfile.

    On subsequent yarn installs, it is omitted, hence the lockfile difference.

    Next step will be figuring out why…

    Edit

    Looks like my initial hunch was wrong about the bundledDependencies. I think the actual problem here is that the metadata from the npm registry: http://registry.npmjs.org/fsevents contains node-pre-gyp as a dependency:

    image

    However once downloaded, the actual fsevents package.json does not:

    {
  "name": "fsevents",
  "version": "1.2.11",
  "description": "Native Access to Mac OS-X FSEvents",
  "main": "fsevents.js",
  "dependencies": {
    "bindings": "^1.5.0",
    "nan": "^2.12.1"
  },
  "os": [
    "darwin"
  ],
  "engines": {
    "node": ">=4.0"
  },
  "scripts": {
    "test": "node ./test/fsevents.js && node ./test/function.js 2> /dev/null"
  },
  "repository": {
    "type": "git",
    "url": "https://github.com/strongloop/fsevents.git"
  },
  "keywords": [
    "fsevents",
    "mac"
  ],
  "author": "Philipp Dunkel <pip@pipobscure.com>",
  "license": "MIT",
  "bugs": {
    "url": "https://github.com/strongloop/fsevents/issues"
  },
  "bundledDependencies": [
    "node-pre-gyp"
  ],
  "homepage": "https://github.com/strongloop/fsevents"
}

    I suspect yarn is using the deps from the registry the first time, then the deps from the downloaded cached package.json the second.

Comments are closed.