Workspaces Don't Respect --frozen-lockfile

[epmatsw]

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

What is the current behavior?
If you have a workspace configured and one of the packages has a change that would require the yarn.lock to change, yarn install --frozen-lockfile in the project root changes the yarn.lock rather than erroring out. Running the same command inside the package itself produces the expected error.
If the current behavior is a bug, please provide the steps to reproduce.

https://github.com/epmatsw/yarn-workspace-frozen-lockfile

In that repository, if you run npm test (which runs yarn install --frozen-lockfile) in the normal directory, you get an error as expected. If you run npm test in the workspaces/subpackage directory, you get an error as expected with 1.0.1, you get no error and the yarn.lock is updated. If you run npm test in the workspaces directory, you get no error and the yarn.lock is updated.

What is the expected behavior?
yarn install --frozen-lockfile should not update the yarn.lock and should produce an error.

Please mention your node.js, yarn and operating system version.
Node 8.4.0, yarn 0.28.1, macOS 10.12.

[epmatsw]

With 1.0.1, this seems to have gotten even worse. Now, if you run yarn install --frozen-lockfile even in the subpackage directory, it will ignore the flag and overwrite the root lockfile.

[edmorley]

I can reproduce this even after the workspaces fixes in yarn 1.2.0. (Note: The STR in the OP are missing the steps to switch into the normal and workspaces directories before running npm test.)

[wyattjoh]

Possibly related? When I clone the following repo at this particular url:

coralproject/talk@8ec933e

I can see that when I run yarn install --frozen-lockfile it installs dependencies, does not touch the lockfile, ok. I then run it without the --frozen-lockfile flag, and it modifies the yarn.lock file. From the cli description, it would appear as though the stated behavior of "don't generate a lockfile and fail if an update is needed" does not actually fail when an update is "needed".

[schmod]

This is still an issue with Yarn 1.13.0, and affects most Lerna workflows.

[cansin]

I am also able to reproduce this with Yarn 1.13.0. Is there a fix on the recent versions of Yarn?

[jbinto]

@cansin Still an issue with 1.15.2.

[cansin]

This bug makes it quite hard for our project to keep yarn.lock and package.json in sync. Does anyone have a workaround suggestion? Is there anything I/we can help to get this issue moving?

[jbinto]

@cansin I've been using the following script in CI with some success:

#!/bin/bash

# This file exists because as of yarn@1.12.3, --frozen-lockfile is completely
# broken when combined with Yarn workspaces. See https://github.com/yarnpkg/yarn/issues/6291

CKSUM_BEFORE=$(cksum yarn.lock)
yarn install
EXIT_CODE=$?
CKSUM_AFTER=$(cksum yarn.lock)

if [[ $CKSUM_BEFORE != $CKSUM_AFTER ]]; then
  echo "yarn_frozen_lockfile.sh: yarn.lock was modified unexpectedly - terminating"
  exit 1
fi

exit $EXIT_CODE

[epmatsw]

Still an issue in 1.17.3.

[bxt]

There seems to be a PR that could fix it: #6554

[pveyes]

You can run ! git diff --name-only | grep yarn.lock after running yarn install to achieve the same behavior. grep will exit with code 0 if found and we use ! to invert the return value. If yarn.lock changes after install, it will exit 1 which then fail the CI

$ yarn install
$ ! git diff --name-only | grep yarn.lock

[paul-soporan]

Closing as this has been fixed in the v2.

https://yarnpkg.com/getting-started/migration