Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Yarn check reports errors after yarn install #6427

Open
nkovacs opened this issue Sep 25, 2018 · 5 comments
Open

Yarn check reports errors after yarn install #6427

nkovacs opened this issue Sep 25, 2018 · 5 comments
Assignees
Labels

Comments

@nkovacs
Copy link

nkovacs commented Sep 25, 2018

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

bug

What is the current behavior?
yarn check outputs the following errors:

error "webpack#ajv" is wrong version: expected "5.5.2", got "4.11.8"
error "webpack#ajv-keywords" is wrong version: expected "2.1.1", got "1.5.1"
error "table#ajv" not installed
error "table#ajv-keywords" not installed

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

yarn init -y && yarn add eslint@3.19.0 webpack@3.2.0 && yarn check

What is the expected behavior?
yarn check should not output any errors

Please mention your node.js, yarn and operating system version.
node.js 8.11.3 and 10.11.0
yarn 1.1.0, 1.4.0, 1.7.0, 1.8.0, 1.9.1, 1.9.4 and 1.10.0 (yarn 1.0.0 does not seem to be affected)
debian 8 and 9

This bug was originally reported as #3916 and #3933, and it was fixed in 1.0.0. I can't reproduce it with 1.9.4 using yarn init -y && yarn add babel-cli@6.24.1 stylelint@7.9.0 webpack@3.1 && yarn check

@ghost ghost assigned arcanis Sep 25, 2018
@ghost ghost added the triaged label Sep 25, 2018
@cprussin
Copy link

@arcanis Just wanted to ping you on this, this appears to have been fixed and then regressed, do you have any suggestions for a workaround that we can use in the meantime?

@betaorbust
Copy link

This is currently throwing a pretty big wrench in my team's development workflow.
Any updates @arcanis?
Thanks!

@arcanis
Copy link
Member

arcanis commented Oct 30, 2018

Hey! Yes and no. Tldr: don't use yarn check (it doesn't put your project at risk).

Despite its name, yarn check is a buggy command that probably shouldn't be used (yarn install doesn't need yarn check to work, and yarn check requires us to maintain a separate logic that we don't have the resources to keep up-to-date). Don't use it. Ideally it should be moved into a separate and generic package that could be used whatever is the package manager you use.

I've juste submitted an RFC to remove it in the next major bump, actually: yarnpkg/rfcs#106

@nkovacs
Copy link
Author

nkovacs commented Nov 5, 2018

I used yarn check in CI to ensure that the lockfile is up to date, to catch things like forgetting to commit the lock file changes or using npm, which would not update yarn.lock.
I guess I'll use yarn install --frozen-lockfile instead in CI.

@clinyong
Copy link

clinyong commented Nov 6, 2018

@arcanis Can we update the doc? It's so confused...

rileyjshaw added a commit to common-voice/common-voice that referenced this issue Dec 9, 2019
We added more tests to CI in dfeb79a, which is great! But some rely on `yarn check`, a ["buggy command that probably shouldn't be used"](yarnpkg/yarn#6427).

From a comment in the linked issue, I've added `yarn install --frozen-lockfile` to CI to ensure the lockfile isn't modified.
rileyjshaw added a commit to common-voice/common-voice that referenced this issue Dec 10, 2019
We added more tests to CI in dfeb79a, which is great! But some rely on `yarn check`, a ["buggy command that probably shouldn't be used"](yarnpkg/yarn#6427).

From a comment in the linked issue, I've added `yarn install --frozen-lockfile` to CI to ensure the lockfile isn't modified.
rileyjshaw added a commit to common-voice/common-voice that referenced this issue Dec 12, 2019
We added more tests to CI in dfeb79a, which is great! But some rely on `yarn check`, a ["buggy command that probably shouldn't be used"](yarnpkg/yarn#6427).

From a comment in the linked issue, I've added `yarn install --frozen-lockfile` to CI to ensure the lockfile isn't modified.
rossta added a commit to rossta/webpacker that referenced this issue Apr 1, 2020
The `yarn check` command has been removed in Yarn 2.0.

The yarn integrity check in Webpacker has commonly been a source of
confusion and frustration among developers. Its behavior at times does
not always match expectation.

Yarn's maintainer has described `yarn check` as buggy and discourages
its use: yarnpkg/yarn#6427 (comment)

This PR removes the yarn integrity check from the Webpacker railtie as
well as references to its setting in Webpacker::Configuration.

The Webpacker::Configuration#check_yarn_integrity= method has been left
in with a deprecation warning to avoid a breaking change.
rossta added a commit to rossta/webpacker that referenced this issue Apr 1, 2020
The `yarn check` command has been removed in Yarn 2.0.

The yarn integrity check in Webpacker has commonly been a source of
confusion and frustration among developers. Its behavior at times does
not always match expectation.

Yarn's maintainer has described `yarn check` as buggy and discourages
its use: yarnpkg/yarn#6427 (comment)

This PR removes the yarn integrity check from the Webpacker railtie as
well as references to its setting in Webpacker::Configuration.

The Webpacker::Configuration#check_yarn_integrity= method has been left
in with a deprecation warning to avoid a breaking change.
rossta added a commit to rossta/webpacker that referenced this issue Apr 1, 2020
The `yarn check` command has been removed in Yarn 2.0.

The yarn integrity check in Webpacker has commonly been a source of
confusion and frustration among developers. Its behavior at times does
not always match expectation.

Yarn's maintainer has described `yarn check` as buggy and discourages
its use: yarnpkg/yarn#6427 (comment)

This PR removes the yarn integrity check from the Webpacker railtie as
well as references to its setting in Webpacker::Configuration.

The Webpacker::Configuration#check_yarn_integrity= method has been left
in with a deprecation warning to avoid a breaking change.
gauravtiwari pushed a commit to rails/webpacker that referenced this issue Apr 11, 2020
* Remove the yarn integrity check

The `yarn check` command has been removed in Yarn 2.0.

The yarn integrity check in Webpacker has commonly been a source of
confusion and frustration among developers. Its behavior at times does
not always match expectation.

Yarn's maintainer has described `yarn check` as buggy and discourages
its use: yarnpkg/yarn#6427 (comment)

This PR removes the yarn integrity check from the Webpacker railtie as
well as references to its setting in Webpacker::Configuration.

The Webpacker::Configuration#check_yarn_integrity= method has been left
in with a deprecation warning to avoid a breaking change.

* Add deployment note in README

It's recommended to use `yarn install --frozen-lockfile` in a deployment
context prior to compiling assets for production. This practice may help
offset potential concerns with the removal of the yarn integrity check,
at least in production environemnts.

* Update README with note about yarn install
aliuk2012 added a commit to DFE-Digital/publish-teacher-training-2022 that referenced this issue Apr 21, 2020
Webpacker 5.1.0 removed yarn integrity checker. This commit ensures that
we also use the yarn.lock we generated while developing rather than updating
it. It should also fail if package.json & yarn.lock are out of sync.

Yarn's own maintainer discourages its use:
yarnpkg/yarn#6427 (comment)
and suggests the following solution:
Solution
Remove the integrity initializer and the configuration options. Encourage
developers to ensure yarn install in local environments and
yarn install --frozen-lockfile as part of deployment.

Other references:
https://classic.yarnpkg.com/en/docs/cli/install#toc-yarn-install-frozen-lockfile
rails/webpacker#2518
aliuk2012 added a commit to DFE-Digital/find-teacher-training that referenced this issue Apr 22, 2020
Webpacker 5.1.0 removed yarn integrity checker. This commit ensures that
we also use the yarn.lock we generated while developing rather than updating
it. It should also fail if package.json & yarn.lock are out of sync.

Yarn's own maintainer discourages its use:
yarnpkg/yarn#6427 (comment)
and suggests the following solution:
Solution
Remove the integrity initializer and the configuration options. Encourage
developers to ensure yarn install in local environments and
yarn install --frozen-lockfile as part of deployment.

Other references:
https://classic.yarnpkg.com/en/docs/cli/install#toc-yarn-install-frozen-lockfile
rails/webpacker#2518
KingTiger001 added a commit to KingTiger001/Rails-web-pack-project that referenced this issue Jan 15, 2023
* Remove the yarn integrity check

The `yarn check` command has been removed in Yarn 2.0.

The yarn integrity check in Webpacker has commonly been a source of
confusion and frustration among developers. Its behavior at times does
not always match expectation.

Yarn's maintainer has described `yarn check` as buggy and discourages
its use: yarnpkg/yarn#6427 (comment)

This PR removes the yarn integrity check from the Webpacker railtie as
well as references to its setting in Webpacker::Configuration.

The Webpacker::Configuration#check_yarn_integrity= method has been left
in with a deprecation warning to avoid a breaking change.

* Add deployment note in README

It's recommended to use `yarn install --frozen-lockfile` in a deployment
context prior to compiling assets for production. This practice may help
offset potential concerns with the removal of the yarn integrity check,
at least in production environemnts.

* Update README with note about yarn install
smartech7 pushed a commit to smartech7/ruby-webpacker that referenced this issue Aug 4, 2023
* Remove the yarn integrity check

The `yarn check` command has been removed in Yarn 2.0.

The yarn integrity check in Webpacker has commonly been a source of
confusion and frustration among developers. Its behavior at times does
not always match expectation.

Yarn's maintainer has described `yarn check` as buggy and discourages
its use: yarnpkg/yarn#6427 (comment)

This PR removes the yarn integrity check from the Webpacker railtie as
well as references to its setting in Webpacker::Configuration.

The Webpacker::Configuration#check_yarn_integrity= method has been left
in with a deprecation warning to avoid a breaking change.

* Add deployment note in README

It's recommended to use `yarn install --frozen-lockfile` in a deployment
context prior to compiling assets for production. This practice may help
offset potential concerns with the removal of the yarn integrity check,
at least in production environemnts.

* Update README with note about yarn install
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

5 participants