Le jeu. 31 juil. 2025 à 23:47, Julian Gilbey <
jdg@debian.org> a écrit :
Dear both,
On Thu, Jul 31, 2025 at 09:39:57AM +0200, Jérémy Lal wrote:
> Le jeu. 31 juil. 2025 à 07:20, Jonas Smedegaard <jonas@jones.dk> a écrit :
>
> Quoting Jérémy Lal (2025-07-31 00:01:23)
> > Le mer. 30 juil. 2025 à 23:14, Julian Gilbey <jdg@debian.org> a écrit :
> >
> > > Hi!
> > >
> > > I'm trying to package nbdime (a Python/NodeJS combo), and I've hit a
> > > snag I can't work out how to resolve. My WIP is on salsa in a
> > > personal fork: https://salsa.debian.org/jdg/nbdime.git
> > >
> > > One of the packages in the repository is webapp, and it is built using
> > > webpack. But webpack throws an error because @rjsf/core imports from
> > > node:crypto (/usr/share/nodejs/@rjsf/core/lib/index.js line 1):
> > > [...]
I think I may have tracked down the source of the problem (though I'm
really not sure). It seems to be the nanoid package, included in
node-postcss. This package includes two different index.js files:
/usr/share/nodejs/nanoid/index.js
/usr/share/nodejs/nanoid/index.browser.js
with the second one targeting browser usage (and not including the
node:crypto import). For some reason, when building @rjsf/core, I
think the index.js file is used rather than the index.browser.js one.
I don't know what the "correct" or "expected" behaviour is, but the
upstream binary package doesn't embed nanoid code, but instead imports
it at runtime. (And I'm looking at the 5.12.1 version as a fair
comparison.)
I've no idea what we're doing differently from upstream :(
This change in behavior might be due to
This would not be a nodejs regression - it would have exposed a misconfiguration in nanoid.
(I'm busy right now so I'll try to look at it next week)
Jérémy