[Pkg-javascript-devel] Yarnpkg future

[Pirate Praveen]

On Mon, Jan 4, 2021 at 12:27 pm, Paolo Greppi <paolo.greppi at libpf.com> 
wrote:
> 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.
> 

That sounds good to me. Go ahead and ask. Though I'm not sure if they 
will be open to it, but no harm in asking.

> 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 ?

Looks good to me.