How to setup a new project directly with yarn 4

[Et7f3]

In this message I might rant a little bit but hope to get a better UX because I really like yarn features and provides view of a newcomer.

I have read Starting with Yarn > Installation but I am unsatisfied:

About corepack:

• It mutate global state
• It install a v1 on the system (even if I start a project so I can directly choose v4)

Without corepack:

• It include a binary blob in git (really easy to sneak some code executed on other users). I understand checksum is not read each time to avoid performance penalty but by being respectful it introduce an easy way to break security.

Explanations

It mutate global state

If I follow first step of the tutorial

bob@344a909b7c8f:~/proj$ corepack enable yarn
Internal Error: EACCES: permission denied, symlink '../lib/node_modules/corepack/dist/yarn.js' -> '/usr/local/bin/yarn'
    at async Object.symlink (node:internal/fs/promises:993:10)
    at async EnableCommand.generatePosixLink (/usr/local/lib/node_modules/corepack/dist/lib/corepack.cjs:42741:5)
    at async EnableCommand.execute (/usr/local/lib/node_modules/corepack/dist/lib/corepack.cjs:42725:11)
    at async EnableCommand.validateAndExecute (/usr/local/lib/node_modules/corepack/dist/lib/corepack.cjs:40485:22)
    at async _Cli.run (/usr/local/lib/node_modules/corepack/dist/lib/corepack.cjs:41460:18)
    at async Object.runMain (/usr/local/lib/node_modules/corepack/dist/lib/corepack.cjs:43415:12)

If I install node/corepack as root like we do in docker (then we switch to another user). Workarounds is to use --installation-root (I think it really want I use this option as seen in this help message):

Unknown Syntax Error: Command not found; did you mean one of:

  0. corepack enable [--install-directory #0] ...
  1. corepack enable [--install-directory #0] ...

Alternatively I can corepack enable when root but we would then have some yarn version managed by root and some other managed in the project (the zero install). It might be disturbing.

It install a v1 on the system

I tried to create a yarn v4 project from scratch with corepack (I cleaned the cache and took an empty folder):
When I run corepack yarn set version 4.0.2 I have then 2 versions installed:

ls  ~/.cache/node/corepack/yarn/
1.22.21  4.0.2

This method almost works but I don't have the questions when you do npm init/yarn init

2. Another method I tried like we can do with python (python3.6 -m venv "my_env_name" to init a project with 3.6):

# corepack use yarn@4.0.2
Installing yarn@4.0.2 in the project...
Internal Error: ENOENT: no such file or directory, open '/package.json'
    at async open (node:internal/fs/promises:633:25)
    at async Object.readFile (node:internal/fs/promises:1242:14)
    at async UseCommand.setLocalPackageManager (/usr/local/lib/node_modules/corepack/dist/lib/corepack.cjs:42901:53)
    at async UseCommand.execute (/usr/local/lib/node_modules/corepack/dist/lib/corepack.cjs:43195:5)
    at async UseCommand.validateAndExecute (/usr/local/lib/node_modules/corepack/dist/lib/corepack.cjs:40485:22)
    at async _Cli.run (/usr/local/lib/node_modules/corepack/dist/lib/corepack.cjs:41460:18)
    at async Object.runMain (/usr/local/lib/node_modules/corepack/dist/lib/corepack.cjs:43415:12)

This doesn't works yet (but it might be on corepack side)

To get this to work I have to echo {} > package.json but later when I use corepack yarn init it doesn't ask me question only name get written.

3. The method that seems to works best is to follow the same scheme (use yarn1 for bootstrap):
   get yarn via other way (npm install -g, npx, nix).
   yarn init
yarn set version 4.0.2

4. seems to be also the case in CI: use v1 to build v4 as convenience binary

Possible solution

npm registry contains only version 1 and 2 (for instance 2.4.3)
I see only yarn 1 and 2 are published on npm. maybe publish with another name like @yarnjs/yarn3 @yarnjs/yarn4 so it use did simply npm install yarn it won't break his project.

Having yarn4 in PATH

curl https://repo.yarnpkg.com/4.0.2/packages/yarnpkg-cli/bin/yarn.js > /usr/local/bin/yarn4 for user root let having yarn4 globally available or I can do in my local bin folder.

So that I can yarn init directly without having a v1 on my system.
It might sound horrific (and it can if you consider a ubuntu/debian system without version locking)

The same but with a manager tools

Node have multiple node version manager n, nvm, fnm, ... why not yarn ?
A tools I like is nix because its goals seems aligned with yarn: try hard to be 100% bit-for-bit reproducible. It manage already multiple version of multiple tools (node, rust, python, c compiler, ...) and can lock node version but also it's system dependencies (libc, compiler, source commit, patch applied, ...):

Here is a one-liner that demonstrate it (but we can have state store in file like yarn): nix shell github:NixOS/nixpkgs?rev=c92e12d81eca4be5fb7b37727eeab3f594c3b8a9#nodejs_21

In 10 years which node will get you: /nix/store/jra6nl09vh0grv4s7m3q778havhs1l6i-nodejs-21.5.0/bin/node if you use a x86_64-linux

We can also use shebang script:
So we can start a shell and all system package are version locked:
https://nixos.wiki/wiki/Nix-shell_shebang#Pinning_nixpkgs

If I understand yarn philosophy: it want to embed inself in git repo because version should be locked. I think I can have best of both world if I let nix manage my nix version.

The UX I envision is something similar to node: nix run nixpkgs#yarn4 init (we have already something like this with yarn v1).

Have you any opinion on this ?

I would glad to integrate yarn with nix as it seems to provides an easy on-boarding and the community have already tried to use the two tools together.

Further integration with nix could help with package that bundle binary blob (because nix can provides a compiler). installation happen in a global store that is remounted read-only and have checksums for each file. So we can't see if it has been tampered.

PS: Nix doesn't have a dependencies solver (it is humans that select version and we try to move all dependencies forward like most distros). So it will always need to co-op with yarn (or force humans to repackage multiples npm projects).