[Pkg-javascript-devel] please bring yarnpkg back to testing

[Pirate Praveen]

On Tue, Sep 15, 2020 at 10:19, Paolo Greppi <paolo.greppi at libpf.com> 
wrote:
> Hi Pravi, see below
> 
> Il 14/09/20 19:01, Pirate Praveen ha scritto:
>> 
>> 
>>  On Mon, Sep 14, 2020 at 17:12, Paolo Greppi 
>> <paolo.greppi at libpf.com> wrote:
>>>  #960120 is keeping yarnpkg out of testing; there are two ways to 
>>> resolve this:
>>> 
>>>  1. work with upstream to fix this mess (not likely to happen as 
>>> upstream seems unresponsive)
>>> 
>>>  2. revert the changes that caused the issue; the last successful 
>>> salsa CI pipeline I can find is this one:
>>>  
>>> https://salsa.debian.org/js-team/node-yarnpkg/-/commit/877478d5ef3f8a7564cdea211e5cd794fdfb97b5
>>>  so just revert all changes to this repo and the build deps to this 
>>> status
>>> 
>>>  I urge those who caused the mess fix it.
>> 
>>  Hi Paolo,
>> 
>>  We discussed about plan to remove babel 6 from bullseye from the 
>> very beginning as upstream won't be supporting it for the life time 
>> of bullseye. You can look at the list archive for those mails. I 
>> think it is only normal to move to new upstream versions of 
>> libraries. We also sent list of affected packages frequently to the 
>> list. No one suggested to keep babel 6 in testing at that time. You 
>> had a chance to request keeping babel 6 before it was removed as 
>> well. Marking for autoremoval was also a warning (node-yarnpkg was 
>> also marked for auto removal when I filed rc bug against 
>> node-babel), you could have requested keeping babel 6 for longer, 
>> though eventually it has to be removed from bullseye if no one steps 
>> up to maintain it.
>> 
>>  If someone wants to keep babel 6, they have to step in and take up 
>> maintenance. Or you could even embed babel 6 in yarnpkg as it is the 
>> only package currently in the archive that does not work without 
>> babel 7. Introducing babel 6 back in testing means supporting babel 
>> 6 and 7 for the life time of bullseye. Are you prepared to do that? 
>> If someone volunteers to maintain babel 6 in bullseye, we can still 
>> introduce it back, though my preference would be to fix yarnpkg or 
>> wait for yarnpkg 2 (which supports babel 7 already), even if it 
>> means missing bullseye and getting it in bullseye-backports.
>> 
>>  This is nothing specific to yarnpkg here, that is how every library 
>> transition works. For example in ruby team, we moved to rails 6 and 
>> the packages that did not support rails 6 were removed from testing 
>> (applications like redmine, open-build-system and diaspora were not 
>> compatible with rails 6). We cannot expect old versions of libraries 
>> will be supported forever in debian.
>> 
>>  Thanks
>>  Praveen
> 
> Probably we don't need babel.
> 
> I made a test in the clean upstream source tree, with a bin/yarn.mjs 
> binary tweaked to load the source from ../src rather than the 
> transpiled & bundled stuff from ../lib:
> 
>     #!/usr/bin/env node
>     import * as cli from '../src/cli/index.mjs';
>     cli.default().catch(function(error) {
>       console.error(error.stack || error.message || error);
>       process.exitCode = 1;
>     });
> 
> For my test, I manually removed all type annotations from 
> src/cli/index.js and saved it to src/cli/index.mjs
> 
> I can run this both in nodejs 12 (there is the "ExperimentalWarning: 
> The ESM module loader is experimental.") and node 14 from 
> experimental (no warning).
> It parses that first file OK, but does not find the modules in 
> /usr/share/nodejs/:
> 
>     Error [ERR_MODULE_NOT_FOUND]: Cannot find package 'commander' 
> imported from /root/yarn/src/cli/index.mjs
> 
> This and the similar errors can be addressed like this:
> 
>     7c7
>     < import commander from 'commander';
>     ---
>     > import commander from '/usr/share/nodejs/commander/index.js';
> 
> Of course we need an automated tool to strip the type annotations and 
> fix the module lookups.
> 
> The typescript transform from this babel replacement should do the 
> first job:
> https://github.com/alangpierce/sucrase
> And probably webpack can do the second.
> 
> In any case I attach the patched src/cli/index.mjs file.
> 
> What do you think, is this a viable route, or do we have an 
> alternative ?

> 
This could work, we have deviated from upstream build system in the 
past. We once did a manual esm to cjs module format conversion with a 
patch to avoid self build dependency of rollup, then we just used 
typescript directly without using rollup-plugin-typescript when rollup 
switched to typescript.

https://babeljs.io/docs/en/babel-plugin-transform-flow-strip-types/ 
this could be used to remove types (only babel 6 we want to remove, we 
can still use babel 7). Then rollup or webpack (rollup may be lighter, 
but either should work) could be used to generate umd.