Remove yarn integrity check #2518
Conversation
rossta
force-pushed
the
feature/chore-remove-yarn-check
branch
from
84ee956
to
579fd77
Compare
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.
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.
rossta
force-pushed
the
feature/chore-remove-yarn-check
branch
from
579fd77
to
3f6e016
Compare
|
Thank you for this contribution hoping this will be merged or solve soon, I started working on a project with webpacker a few days ago and I have been constantly seeing this error message despite no changes to Javascript dependencies. It goes away once I run In other projects I do use the same approach frozen lock, not only for |
|
thanks @rossta been thinking to remove this from a while 🍰 |
Adopt changes from Webpacker 5.1.0 rails/webpacker#2518
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
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
Should Rails do a |
Are you serious? If I don't run The least you should do in such a PR is to draw a hopeful picture by referencing Yarn 2.0 (Yarn Plug’n’Play) |
Oh no, that's terrible. Right now when switching between development branches, I frequently get the yarn integrity check warning. If the alternative post this change is silent failing... that is disastrous. This stuff is very hard to debug. Even for "intermediate" devs (with JS) like me -- beginners are going to be absolutely stymied. I get that if yarn itself is removing the feature what you can do.... but I couldn't remove it from webpacker until yarn removes it, and I would prioritize figuring out another solution that will avoid silent hard to debug failures. I see the point of webpacker as a good default integration that saves you from some of the really difficult parts of the JS toolchain world... this is really falling down, if it's true that it will be silent failures when your node_modules are out of sync with yarn.lock. This definitely does happen a lot when switching between dev branches. |
|
We could find a way to detect false positives and address them. I disabled this feature using the configuration flag because I was getting integrity issues despite no changes to dependencies, it would not install anything after |
|
@schmijos I feel your pain. Switching branches in any NPM-managed project is a problem. There are a bunch of blog posts about working around this issue such as with git hooks, git worktree, or checking in node_modules, etc. None of those ideas are perfect but it’s not like there aren’t alternatives. The yarn integrity check didn’t work as advertised. It interfered as often as it helped. The yarn maintainer said it shouldn’t be used. If it worked for you, you could certainly add it back to your workflow. My opinion is that Webpacker shouldn’t try to solve a weakness in JavaScript package management. But I also want this project to succeed. Since you sound motivated, I’d be interested to see how you could help through a pull request. |
|
@rossta thank you for bringing that up, you reminded me to share my solution for this, which is using git hooks https://gist.github.com/cabello/416baa581631779d991b88c265b209aa It bundle installs if Gemfile.lock changed, it yarn install if yarn.lock changed and a few other goodies. It works quite well for my use case. |
…commit fixes a fresh clone
Problem
The yarn integrity check is often a cause of confusion and frustration for developers: #2517, #2322, #1568
That it is run in an initializer and potentially interferes with any Rails command that boots the environment is also surprising to many: #1135
Yarn's own maintainer discourages its use: yarnpkg/yarn#6427 (comment)
The
yarn checkcommand has also been removed from Yarn 2.0.Solution
Remove the integrity initializer and the configuration options. Encourage developers to ensure
yarn installin local environments andyarn install --frozen-lockfileas part of deployment.