On Tue, Sep 15, 2020 at 10:19, Paolo Greppi <paolo.gre...@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.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 ?
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.
--
Pkg-javascript-devel mailing list
Pkg-javascript-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
