yarn berry not being used if you follow the documentation

[darkbasic]

https://github.com/mikro-orm/mikro-orm/blob/master/CONTRIBUTING.md#submitting-a-pull-request

According to your documentation corepack enable followed by yarn should be enough to get started.
Unfortunately that way you end up using the deprecated yarn v1.
To use yarn v3 you will have to run yarn set version berry first:

➤ YN0000: Retrieving https://repo.yarnpkg.com/3.4.1/packages/yarnpkg-cli/bin/yarn.js
➤ YN0000: Saving the new release in .yarn/releases/yarn-3.4.1.cjs
➤ YN0000: Done in 0s 810ms

which also sets the yarnPath:

diff --git a/.yarnrc.yml b/.yarnrc.yml
index 3186f3f0..fc8ec93a 100644
--- a/.yarnrc.yml
+++ b/.yarnrc.yml
@@ -1 +1,3 @@
 nodeLinker: node-modules
+
+yarnPath: .yarn/releases/yarn-3.4.1.cjs

Also you gitignored .yarn/plugins and .yarn/releases which contain the Yarn releases used in the current repository (as defined by yarn set version): https://yarnpkg.com/getting-started/qa#which-files-should-be-gitignored

[B4nan]

You might need to do corepack prepare yarn@stable --activate, that's all. Will add that to the guide.

Also you gitignored .yarn/plugins and .yarn/releases which contain the Yarn releases used in the current repository (as defined by yarn set version): yarnpkg.com/getting-started/qa#which-files-should-be-gitignored

I did, on purpose, as I don't want to commit yarn binaries to the repository. Using corepack is alternative to that, there is no point in using corepack if you commit them.

From yarn docs:

The preferred way to manage Yarn is through Corepack, a new binary shipped with all Node.js releases starting from 16.10. It acts as an intermediary between you and Yarn, and lets you use different package manager versions across multiple projects without having to check-in the Yarn binary anymore.

[B4nan]

Maybe switch to fnm right ahead, it's much faster (no lag on opening new terminal).

https://github.com/Schniz/fnm

[darkbasic]

Good idea, I was too lazy to check out if it builds on ppc64le but it should probably be fine and I've had enough headaches with nvm anyway.

[darkbasic]

Turned out fnm does indeed NOT work on ppc64le, but I've managed to find an IBM branch of ring which compiles fine, at least if you keep around your .git directory. fnm is still somehow broken because it thinks to be on amd64 and it downloads x64 binaries but the workaround is easy enough at this point.
The good news is that now it works like it should:

niko@talos2 ~ $ whereis yarn
yarn: /usr/bin/yarn

niko@talos2 ~ $ corepack enable

niko@talos2 ~ $ whereis yarn
yarn: /usr/bin/yarn /home/niko/.local/share/fnm/node-versions/v18.15.0/installation/bin/yarn

niko@talos2 ~ $ yarn --version
3.4.1

Unfortunately once you enable yarn 3 via corepack enable it forces yarn berry onto every yarn legacy project. Do you know how to avoid such behaviour?

[B4nan]

I believe you can use corepack prepare yarn@1 --activate outside of a project directory.

[darkbasic]

That did the trick, but now the following vscode task fails whenever I work on the mikro-orm code base:

Jest (mikro-orm)

[info] auto config:

found:
  rootPath: /home/niko/devel/mikro-orm
  jestCommandLine: yarn test


error @mikro-orm/[email protected]: The engine "yarn" is incompatible with this module. Expected version ">=3.2.0". Got "1.22.19"
error Commands cannot run with an incompatible environment.


[error] failed to retrieve test file list. TestExplorer might show incomplete test items