Ich verwende für meine Projekte nix flakes und möchte die Tools damit installieren.

Ich habe also im nix-flake yarn-berry installiert und mich gewundert, dass yarn immer noch in Version 3.6.1 lief:

yarn --version
3.6.1

Als ich überprüft habe woher yarn kommt, laut which sollte es aus dem Nix Store in Version 4.12.0 kommen:

which yarn
/nix/store/2pmvaaggpi7ikx9xmhy3x2j0rpklaqrv-yarn-berry-4.12.0/bin/yarn

Es wird aber in der .yarnrc.yml auf ein lokales yarn aus dem Repository verwiesen:

yarnPath: .yarn/releases/yarn-3.6.1.cjs

welches dann sehr einfach präpariert werden kann. Ein Beispielrepository habe ich hier veröffentlicht: https://github.com/twaldecker/yarn-releases

Ein Ablauf könnte dann z.B. so aussehen:

$ git clone https://github.com/twaldecker/yarn-releases.git yr
Cloning into 'yr'...
remote: Enumerating objects: 20, done.
remote: Counting objects: 100% (20/20), done.
remote: Compressing objects: 100% (14/14), done.
remote: Total 20 (delta 3), reused 20 (delta 3), pack-reused 0 (from 0)
Receiving objects: 100% (20/20), 857.94 KiB | 2.17 MiB/s, done.
Resolving deltas: 100% (3/3), done.

$ cd yr
# hier erwartet man, sein eigenes yarn aus seinem lokalen System zu verwenden...
$ yarn install
owned
➤ YN0000: ┌ Resolution step
➤ YN0000: └ Completed
➤ YN0000: ┌ Fetch step
➤ YN0000: └ Completed
➤ YN0000: ┌ Link step
➤ YN0000: └ Completed
➤ YN0000: Done in 0s 37ms

Abhilfe

Ich verwende aus diesem und weiteren Gründen pnpm als Paketmanager.

Man kann auch yarn konfigurieren, dass es das lokale yarn ignoriert. Dazu setzt man entweder die Umgebungsvariable YARN_IGNORE_PATH=1 oder setzt die Konfiguration ignorePath: true in der Systemweiten Konfiguration.

Man muss also die Umgebungsvariable setzen, um die Manipulation zu umgehen:

$ export YARN_IGNORE_PATH=1
$ yarn install
➤ YN0087: Migrated your project to the latest Yarn version 🚀
➤ YN0000: · Yarn 4.12.0
➤ YN0000: ┌ Resolution step
➤ YN0000: └ Completed
➤ YN0000: ┌ Fetch step
➤ YN0000: └ Completed
➤ YN0000: ┌ Link step
➤ YN0000: └ Completed
➤ YN0000: · Done in 0s 53ms

Es gibt ein Issue zu YARN_IGNORE_PATH, dass aber nicht wegen dieser Lücke existiert:
https://github.com/yarnpkg/berry/issues/1078

Bewertung

Man kann jetzt natürlich argumentieren, dass man nicht einfach so fremde Repositories klont und deren code ausführen sollte. Aber in diesem Fall glaubt der Anwender, dass er sein eigenes yarn ausführt, was leider nicht der Fall ist.

Ich denke, dass einigen Entwicklern dieses Verhalten von yarn nicht klar ist.

Es gibt auch die Angriffe, bei denen aus den Paketen bei der Installation Code ausgeführt wurde. Diese "Funktion" ist in npm immer noch vorhanden.