yarn set version latest downloads a Yarn release to <projectRoot>/.yarn/releases/yarn-<version>.cjs.
When yarn is ran in the project's root, does Yarn automatically use the version included in the aforementioned folder, or does it use the global version?
If it doesn't use it automatically, I assume the engineer working with the project is supposed to just node path-to-release it?
It uses the version at <projectRoot>/.yarn/releases/yarn-<version>.cjs because yarn set version latest adds to .yarnrc an entry like this yarn-path ".yarn/releases/yarn-<latest-version>.cjs".
yarn-path "./bin/yarn"
Instructs yarn to defer to another Yarn binary for execution.
https://classic.yarnpkg.com/en/docs/yarnrc#toc-yarn-path
Related
I am using yarn to install a package from a .tgz. When I update the package and install it again, yarn uses an old cached version of the package. Here is a report from someone running into a similar problem. If I try to delete the package from the cache, it gives me errors, and if I use yarn cache clean it will clear the whole cache, which is also not what I want.
The reason the package is changing is that I am developing it, and don't want to bump the version number every five minutes. I read maybe newer yarn versions take the package hash into account when installing, but I am stuck with version 1.22.1 (actually jlpm which is JupyterLab's vendored version of yarn).
Is there a way to say yarn add package-0.1.0.tgz --dont-use-cache? Or should I just skip yarn and use npm, or something else on top?
I'm on yarn version 3.2.0 and trying to deploy a project on Heroku and it's telling me that I need the yarnrc.yml file but it is missing. I've tried running yarn, yarn install, yarn set version berry, and yarn set version stable but the file will not auto generate. I also created a brand new project and tried yarn init -2 but still no rc file.. Any suggestions?
had the same problem, I ended up creating the file by myself.
Take care, that the error message from Heroku is missleading and the file requires a prefixed dot: .yarnrc.yml
First line is for opting out of Plug&Play, second line points to the local yarn release (might depend on your version)
nodeLinker: node-modules
yarnPath: .yarn/releases/yarn-3.2.1.cjs
I have a yarn/lerna monorepo with multiple packages that depend on each other. If I add packageA as a dependency to packageB and execute yarn install I see that node_modules/packageA is actually a symlink to packages/packageA instead of the published version of that package.
This creates problems on CI if packageB is build before packageA - the build fails because node_modules/packageA just points to the bare sources, without the build products (because packageA has not yet been built).
How can I force yarn to always download the published version of packageA?
yarn --version: 1.22.10
sidenote: If I wanted to use a local version of packageA instead, I would use yarn link or a local path instead of a version in package.json. Why is yarn defaulting to this behaviour?
One options is: "focussed workspaces" - see the guide here.
In my case, I added a file packages/packageB/.yarnrc that specifies to always use the --focus argument for yarn install:
--install.focus true
This will make sure that packageB has a copy of the published packageA in it's own node_modules folder.
However: This only works for one package at a time.
You can just build packages in order of dependencies. So in your case it'd be something like this in your CI (assuming there is a script entry called "build" in package.json of the packages):
yarn workspace packageA run build
yarn workspace packageB run build
This way you control the order of builds,they complete successfully, and you don't have to force using published package.
In the next version of yarn ("berry") the manual states that one should just commit the directory created called .yarn, but if you use the multi-version setup for yarn, this directory contains the file releases/yarn-berry.js which seems to be the entire berry version of yarn, taking up more than 2MB of disk.
This just seems really wrong - why should I commit a package manager to git, just to get it to work?
The Yarn developers explain the rationale for this in the Installation docs, in the section called "About global installs":
Using a single package manager across your system has always been a problem. To be stable, installs need to be run with the same package manager version across environments, otherwise there's a risk we introduce accidental breaking changes between versions - after all, that's why the concept of lockfile was introduced in the first place! And with Yarn being in a sense your very first project dependency, it should make sense to "lock it" as well.
Once Yarn is tracked and "locked" as a per-project dependency, it ends up getting committed to Git if you follow Yarn 2's zero-install strategy, the rationale for which is explained here.
I'm a newcomer to Yarn, but I spent years working devops, helping developers figure out why their code would sometimes build correctly on half of the team's laptops but not on the other half, or would suddenly start failing to build in CI while continuing to work elsewhere. Trying to keep the version of npm consistent across every computer and codebase in the company was essentially impossible, given that Node is constantly being upgraded, but locking each project to its own specific version of Yarn -- which, by being committed to Git, is guaranteed to be available in every checkout of that project -- solves this problem.
I have written a small tool for those people who don't want to commit Yarn 2+ binary into their git repos, while still benefiting from sticking Yarn version per project. If you already have Yarn 2+ configured in your project just don't want to commit it, you can run:
yarn dlx pinyarn
This command will generate .pinyarn.js (4KB) which you should commit, instead. .pinyarn.js will contain URLs inside to download Yarn 2+ and its plugins from the official Yarn Berry GitHub repo. .pinyarn.js will download binary and plugins from these URLs if they are not downloaded yet.
You can also specify which version of Yarn 2+ you want via:
yarn dlx pinyarn 3 - the latest released Yarn 3 version, or
yarn dlx pinyarn 2.2.2 - version 2.2.2, or
yarn dlx master - version from latest sources, or
yarn dlx 1638 - version from Pull Request 1638
The pinyarn tool repo on GitHub:
https://github.com/sysgears/pinyarn
The official documentation mentions what's should be ignored and what should be committed. It can solve this problem I think.
https://yarnpkg.com/getting-started/qa#which-files-should-be-gitignored
The new docs states using node's newest corepack feature (to date).
This means that when using appropriate node you only need to place a valid packageManager field value in package.json and run corepack enable, e.g.
{
"name": "foo",
"packageManager": "yarn#3.2.0",
"scripts": {
...
}
}
Say I have a package.json file in an existing project. In there I have "some-package": "^1.0-01",, however I know that the latest version is 1.0-02
So I do yarn upgrade. However, package.json is not update, and still references the -01 version. The yarn.lock file however shows this:
some-package#^1.0-01:
version "1.0-02"
Is this expected behavior? When someone else does the yarn command, which version will they get. If they get the latest version, isn't it misleading to show -01 in package.json?
According to the documentation here,
yarn upgrade
This command updates all dependencies to their latest version based on
the version range specified in the package.json file. The yarn.lock
file will be recreated as well.
The tricky part is based on the version range specified in the package.json
This means that if your package.json has defined a particular semver like you've said, upgrade will only upgrade it according to the range defined there, i.e. ^1.0-01 should upgrade to 1.0-02 in both your package.json and yarn.lock files.
Now you've said that this is happening only in your yarn.lock file. Yarn provides a utility for checking for such clashes called check
Could you try running
yarn check
in your repository and tell us your findings?