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.gre...@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 ?
Paolo
index.mjs.txt.gz
Description: application/gzip
-- Pkg-javascript-devel mailing list Pkg-javascript-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
