[Pkg-javascript-devel] Yarnpkg future

[Paolo Greppi]

The good news of 2020 was the successful team effort (thanks again Akshay S Dinesh and Pirate Praveen !) to keep yarnpkg in bullseye.

Tha bad news of 2021 has been these issues being closed by upstream:
https://github.com/yarnpkg/yarn/issues/8081
https://github.com/yarnpkg/yarn/issues/8083
https://github.com/yarnpkg/yarn/issues/8417

So yarn2 is the future, but yarn1 is still required to “install” it.
More precisely to "vendor" it, i.e. to install in each repo a copy of the package manager binary compatible with the package.json / yarn.lock dialect or mode or flavor that particular repo is using.

If this sounds crazy, read these issues on the yarn2 (“berry”) upstream:
https://github.com/yarnpkg/berry/issues/181
https://github.com/yarnpkg/berry/issues/2216

As it has been in the last 25 years, the JavaScript ecosystem is a moving target (besides yarn2’s pnp mode there is pnpm and deno (https://bugs.debian.org/961337) ...) and it does not help to be ideological.
 From Debian (or any distribution) POV it’s OK if users choose to use the tools we provide in suicidal ways (piping curl into sudo bash, depending on registries and binary downloads for each and every build, vendoring binaries etc.).
We all do, by the way !

Our only concern should be to also make it possible to use these same tools in a sane way, for example making it possible (at some point in the future) to reproducibly build a signal-desktop (https://bugs.debian.org/842943) binary from clearly identified sources and without network access. Ah, and of course maintaining all that in the mid term.

I propose that as js-team we open a single issue on the yarn2 (“berry”) repo, with the request to drop yarn1 and to support yarn2 as the only globally installed yarnpkg version on the system.
In that case if I init a new “yarn2” repo with my global yarn2 binary, it does not need to vendor itself.
But it would vendor yarn1 if you have a legacy repo. Of vendor yarn3 if you want to use yarn-next.
When yarn3 becomes stable, upgrade the globally installed yarnpkg version to that and so on.

Debian’s baseline task would be to only support the current stable yarnpkg version (yes, that will be fun for “berry” see: https://bugs.debian.org/976081#63).
And supporting the oldstable version (as we’re doing with yarn1 in bullseye) only if required.

What do you think ?

Paolo