[Pkg-javascript-devel] Bug#976331: Bug#976331: Bug#976331: Bug#976331: Bug#976331: node-compression-webpack-plugin, node-copy-webpack-plugin, node-uglifyjs-webpack-plugin: contains hidden embedded nodejs module serialize-javascript

[Jonas Smedegaard]

Quoting Xavier (2020-12-03 15:44:48)
> Le 03/12/2020 à 15:12, Jonas Smedegaard a écrit :
> > Quoting Xavier (2020-12-03 14:35:25)
> >> Le 03/12/2020 à 14:24, Xavier a écrit :
> >>> Le 03/12/2020 à 12:44, Jonas Smedegaard a écrit :
> >>>> These source packages embed nodejs module serialize-javascript 
> >>>> without offering it as virtual binary package:
> >>>>
> >>>>  node-compression-webpack-plugin
> >>>>  node-copy-webpack-plugin
> >>>>  node-uglifyjs-webpack-plugin
> >>>>
> >>>> Please embed in only one source package provided as versioned 
> >>>> virtual package, and drop in other source packages instead 
> >>>> depending on the virtual package.
> >>>>
> >>>> Severity raised since the lack of virtual package blocks upgrading 
> >>>> node-terser.
> > 
> > [...]
> > 
> >>> for now, dh-sequence-nodejs adds a "Provides" item for modules 
> >>> installed in root nodejs directories. Do we want to declare a 
> >>> "node-foo" for submodules (installed in a <package>/node_modules 
> >>> directory) ?
> > 
> > Whatever that tool does, the resulting package should declare 
> > Provides: for each embedded Nodejs module, properly versioned with 
> > the module's own version as first segment then "~" then source 
> > package version.
> > 
> > I cannot see a reason for *any* embedded Nodejs module to stay 
> > hidden, but if someone comes up with some exceptional cases for 
> > that, then the reasoning should be explicitly documented in either 
> > README.source or README.Debian (and possibly in long description 
> > too).
> 
> I chose that because such modules are not directly usable using a 
> `require("foo")`, but I can change

I am less interested in why historically some pattern was chosen.

My interest is in what pattern to use going forward.

Code in package have dependencies on code in other packages.

We need to be able to declare dependencies between pieces of code.

For JavaScript, code is grouped as "Nodejs modules".

A a concrete example, Nodejs module rollup-plugin-terser depends on 
Nodejs module serialize-javascript.

Going forward (regardless of why historically some other pattern was 
chosen), Debian package node-rollup-plugin-terser needs to be able to 
express a build-dependency on Debian package providing the Nodejs module 
serialize-javascript.


> >> Note that the future lintian database (classification tags) will 
> >> permit to see node modules everywhere.
> > 
> > Everywhere?
> 
> Sorry, I miss some explanations: lintian parses all files and emit a tag
> each time it finds a node_module/foo/package.json or
> <main nodejs>/foo/package.json or <main nodejs/foo.js. Then we will be
> able to see nodejs embedded module in all Debian packages.

Lintian can help check if a package is valid.

Lintian cannot make a package declare as virtual Debian packages the 
Nodejs modules it has embedded.


> NB2, you can also take a look at
> https://lintian.debian.org/tags/nodejs-module-not-declared.html : it
> shows node module installed in nodejs main dirs (not in node_modules/
> for now).

A web page (generated by lintian or written any other way) cannot make a 
package declare as virtual Debian packages the Nodejs modules it has 
embedded.


> If we decide to change this ~policy, nodejs-module-not-declared should 
> also be updated.

I am pretty sure that hiding generally usable embedded code violates a 
"should" somewhere in Debian Policy.

Therefore, if Debian JavaScript Policy says that generally useful 
modules should be *hidden* instead of provided as virtual packages, then 
I consider Debian JavaScript Policy broken.


> But in this case, we will have some not-directly-usable node-* virtual 
> packages.

Why not-directly-usable?

Obviously we should not _only_ declare "Provides:" but also make sure 
that the code is actually placed in the correct location below 
/usr/share/nodejs and check testsuite and establish autopkgtest and all 
the other things that is required for packaging code.

Embedded code is not magically excluded from getting properly packaged.


> > I should be able to declare this in some other package:
> > 
> >    Build-Depend: node-serialize-javascript (>= 5)
> > 
> > That is not possible today, because no packages provide that name 
> > (despite 3 packages containing some version of it).
> > 
> > That will be possible if tommorrow one of those packages adds this:
> > 
> >   Provides: node-serialize-javascript (= 5.0.1)
> > 
> > That will *not* be possible, however, if tommorrow 
> > dh-sequence-nodejs automatically adds this for all three packages:
> > 
> >   Provides: $embeddedmodule (= ${embeddedmodule:Version})
> 
> It does (see our discussion about acorn) but only for main installed
> modules (and if DD didn't omit ${nodejs:Provides} of course)

What I talk about is that generally usable embedded node modules should 
be "installed modules".


> NB: maybe I misunderstood part of your explanations and then my
> explanations are perhaps out of subject

Hope I made it clearer now... :-)


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: signature
URL: <http://alioth-lists.debian.net/pipermail/pkg-javascript-devel/attachments/20201203/bf1598a6/attachment.sig>