yarn install --frozen-lockfile is not failing as expected

[DavideDaniel]

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

Bug

What is the current behavior?
yarn install --frozen-lockfile does not generate a new yarn.lock but it does NOT fail as expected.

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

1. Have a yarn.lock with a package.json with some dependencies and no diffs.
2. Remove a dependency in your package.json (npm uninstall --save something)
3. yarn install --frozen-lockfile proceeds with install instead of failing as docs say, and does not generate a new yarn.lock to reflect the change in package.json.

What is the expected behavior?
Per docs: Don’t generate a yarn.lock lockfile and fail if an update is needed.
It should fail as expected as CI builds need to break earlier rather than wait for build and then fail on a missing or mismatched dependency.

Please mention your node.js, yarn and operating system version.
Node 8.9.1 | 9.6.1
npm 3.10.10 | 5.6.0
MacOS 10.12.6

[DavideDaniel]

Closing this ticket as it was due to modifications in config files related to repos and not yarn

[DavideDaniel]

Actually I need someone else to validate this as the issue is persisting despite us trying to fix things on our end.

[DavideDaniel]

Turns out there were some things wrong on our end but there is still an issue with yarn install --frozen-lockfile - I've edited the title and the original post to reflect that.

yarn install --frozen-lockfile does not generate a new yarn.lock but it does NOT fail as expected.

I realize in the reproduce steps I said to use npm uninstall rather than yarn remove. It's on purpose to reflect realities of working on a shared codebase where someone might either manually manipulate the package.json or use npm client out of habit.

[DavideDaniel]

I haven't had a chance to validate but a starting point might be https://github.com/yarnpkg/yarn/pull/5572. In trying to address https://github.com/yarnpkg/yarn/issues/4778, code was deleted that would cause frozen-lockfile check to fail.

[devrelm]

@DavideDaniel I'm seeing the same issue with --frozen-lockfile not throwing an error.

@torifat Have you had an opportunity to look into this?

[devrelm]

@arcanis Is there any movement on this? There hasn't been any response from the assignee or anyone else within the Yarn org.

[arcanis]

yarn install --frozen-lockfile proceeds with install instead of failing as docs say, and does not generate a new yarn.lock to reflect the change in package.json.

I don't understand. What makes you think it should fail? If you remove dependencies from your package.json, your lockfiles might now contain extraneous useless entries that could be optimized away, but it'll still install things in a repeatable way without having to be modified (so no error needed).

Does that make sense?

[devrelm]

@arcanis From the docs:

yarn install --frozen-lockfile

Don’t generate a yarn.lock lockfile and fail if an update is needed.

It should fail because the docs says it will. It is what separates it from --pure-lockfile.

We need this functionality to catch cases on our ci where a developer updates a dependency without updating the lockfile. Otherwise every other developer that pulls down the commit ends up with a modified yarn.lock when they run yarn, forcing one of them to open a one-off PR just to update the lock.file.

[devrelm]

@arcanis It looks like --frozen-lockfile might only be broken for workspaces. I've set up a minimal repo here that reproduces the issue:

https://github.com/devrelm/frozen-lockfile

[arcanis]

It should fail because the docs says it will. It is what separates it from --pure-lockfile.

No, pure-lockfile simply doesn't write the changes.

• default = Update the lockfile if we want/need
• pure = Update the lockfile if we want/need, but doesn't write it
• frozen = Throws if the lockfile need to be modified

I can see why you'd think frozen-lockfile should throw on this occasion tho. If you're willing to open a PR, I can review it.

[Gudahtt]

@arcanis So --frozen-lockfile will only throw if the updates are required, and will not complain if there are potential optimizations to be made to the lock file (e.g. deleting a package). Is that correct? That might explain the OP's problem. Also this might be something to keep in mind for #5847

Nonetheless, the problem demonstrated by the repo @devrelm created doesn't meet that description. In that repo, a workspace dependency is updated to require a different version than is present in the lockfile. That means that an update to the lockfile is strictly required, yet --frozen-lockfile still doesn't throw.

I've experienced the same problem, and I also suspect that it's only broken for workspaces. Even adding an entirely new dependency in a workspace doesn't seem to make --frozen-lockfile fail.

Perhaps we should create a separate ticket, as it does appear that it might be a different problem than described in the OP.

[Gudahtt]

I've created a failing test here: https://github.com/Gudahtt/yarn/tree/workspace-frozen-lockfile

[edmorley]

I just ran into this (package removed from package.json and the PR author had forgotten to update yarn.lock, but yet CI succeeded) - and it was very surprising to see that it's expected for --frozen-lockfile to succeed in this case.

I totally understand that some optimizations (eg general yarn.lock overlapping versions consolidation) shouldn't result in a --frozen-lockfile failure, but forgetting to update the lockfile after a package was removed seems much more significant than that.

[Gudahtt]

I have created #6291 for the workspace-specific problem discussed here.

@DavideDaniel can you reproduce this problem in a project that isn't using workspaces? If not, perhaps this ticket can be closed.

[edmorley]

Mine occurred when not using a workspace.

[Gudahtt]

@edmorley Ah, right. I think there are two distinct issues here, and yours is the other one. Sorry for the confusion.

The first issue is the situation described by you , where --frozen-lockfile succeeds even if there are optimizations to be made (i.e. packages to remove). This behavior is intentional, though there are good arguments to be made that this behavior should be changed. The documentation should definitely be improved here (#5847), but I don't think it's a bug.

The second issue is when updates are absolutely required, but --frozen-lockfile still succeeds. This is definitely a bug, and we have only seen it occur with workspaces. It was brought up here because the situation was similar, but it's a separate issue.

It looks like the OP was in the same situation as you, where the command was behaving as designed but in confusing manner not well explained by the documentation. But I'm not completely certain of that. I wanted to know from the OP whether they only encountered this problem when removing packages (just as you), or whether they encountered it when adding packages as well (but just chose to use removal as an example in the issue description).

[kachkaev]

Our current workaround in a Linux-based CI environment:

yarn install

git diff yarn.lock
if ! git diff --exit-code yarn.lock; then
  echo "Changes were detected in yarn.lock file after running 'yarn install', which is not expected. Please run 'yarn install' locally and commit the changes.";
  exit 1;
fi

The problem remained unnoticed for months 😅

[jbinto]

We have a similar workaround to @kachkaev

#!/bin/bash

# This file exists because as of [email protected], --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
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

[erikmueller]

Could we move forward with this PR https://github.com/yarnpkg/yarn/pull/6554?

[devrelm]

@arcanis Can you check out #6554, please?