-
Notifications
You must be signed in to change notification settings - Fork 73
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
fix: configure Yarn to always use yarn@1.22.22 #599
base: main
Are you sure you want to change the base?
Conversation
@@ -61,5 +61,6 @@ | |||
"hooks": { | |||
"pre-commit": "lint-staged" | |||
} | |||
} | |||
}, | |||
"packageManager": "yarn@1.22.22" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"packageManager": "yarn@1.22.22" | |
"packageManager": "yarn@1.22.22+sha1.ac34549e6aa8e7ead463a7407e1c7390f61a6610" |
This matches how we have it set over in Forge.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, is that meant to match the sha1 of the vendored Yarn file? I get something different locally, but perhaps I'm hashing the wrong thing?
shasum -a 1 .yarn/releases/yarn-1.22.22.cjs
870faaceb1604f213264cfa69f7db5b620d086b2 .yarn/releases/yarn-1.22.22.cjs
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The way we pulled it for Forge was using the output of npm show yarn@XYZ
- not sure if a different approach is needed in this case with the file being vendored.
$ npm show yarn@1.22.22
yarn@1.22.22 | BSD-2-Clause | deps: none | versions: 120
📦🐈 Fast, reliable, and secure dependency management.
https://github.com/yarnpkg/yarn#readme
bin: yarn, yarnpkg
dist
.tarball: https://registry.npmjs.org/yarn/-/yarn-1.22.22.tgz
.shasum: ac34549e6aa8e7ead463a7407e1c7390f61a6610
.integrity: sha512-prL3kGtyG7o9Z9Sv8IPfBNrWTDmXB4Qbes8A9rEzt6wkJV8mUvoirjU0Mp3GGAU06Y0XQyA3/2/RQFVuK7MTfg==
.unpackedSize: 5.3 MB
maintainers:
- byk <ben@byk.im>
- bestander <bestander@gmail.com>
- daniel15 <npm@d.sb>
- arcanis <nison.mael@gmail.com>
- danbuild <build@dan.cx>
dist-tags:
berry: 2.4.3 latest: 1.22.22 legacy: 1.21.1 rc: 1.22.0
published 3 months ago by arcanis <nison.mael@gmail.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In this case it might be unnecessary since we're vendoring the file itself.
Several parts of
build-tools
call Yarn vianpx yarn
calls. This code assumes that the globally installed Yarn version is 1.x, and some of the calls likenpx yarn --prod
fail if you have a newer version of Yarn installed.Yarn has the ability to specify a desired Yarn version in your repo, and whatever
yarn
command you have on your path will act as a shim and call into the configured Yarn. This is configured by callingyarn set version
, which I have done to generate this PR: https://yarnpkg.com/cli/set/versionFrom some basic testing, it seems that any version of Yarn >=1.18.0 understands this
yarn set version
command and mechanism.Since this PR effectively vendors a bunch of 3rd party code into the repo, it would probably be a good idea for someone with the commit bit to ensure that the vendored bits actually match the upstream url, or to simply run the
yarn set version
command yourself, similar to how only committers can generate a newyarn.lock
.