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

--
Pkg-javascript-devel mailing list
Pkg-javascript-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

Reply via email to