[Pkg-javascript-devel] Bug#976341: Bug#976341: node-jest: please provide real (not virtual) package node-jest-worker

[Jonas Smedegaard]

Quoting Xavier (2020-12-03 18:30:54)
> Control: tags -1 + confirmed
> 
> Le 03/12/2020 à 18:07, Jonas Smedegaard a écrit :
> > node-rollup-plugin-terser has a runtime dependency on 
> > node-jest-worker.
> > 
> > Currently node-jest-worker is provided as a virtual package by jest. 
> > Problem with that is the size of the dependency tree...
> > 
> > rollup+node-rollup-plugin-terser+jest:             334 pkgs / 182 MB
> > 
> > rollup+node-rollup-plugin-terser+node-jest-worker: 136 pkgs / 107 MB
> > 
> > I.e. the size is approximately half with node-jest-worker separate 
> > from jest.
> > 
> > 
> > Please provide real (not virtual) package node-jest-worker,
> > and have jest depend on or recommend that, as appropriate.
> > 
> > 
> >  - Jonas
> > 
> > Hint: Introducing a new package causes a visit the the NEW queue,
> > which potentially can require some time for processing.  To avoid
> > such waiting time stalling other development of the jest package
> > it can be beneficial to first mae a release to experimental
> > (where it can linger while other releases are made to unstable).
> 
> According to https://people.debian.org/~yadd/jest-spaghetti-dish.png
> this makes sense. Do you see some other jest parts that should be separated?

Sorry, I have only closely examined the virtual package that I concrete 
have a need for.

It makes fine sense to me that node-jest-worker was provided only as a 
virtual package until now.  If you want to do more now than switching 
that one binary package from virtual to real, then the most sensible to 
me is to make sure _all_ embedded modules are provided as virtual 
packages to encourage _others_ to collaborate on that larger ongoing 
process of refining pakcage relations.

Viewed generally, decoupling binary packages can be separated into 
multiple steps...:

 1) provide embedded modules as packages - virtual or not - to allow 
    declaring explicit package relations.

 2) declare explicit package relations.

 3) examine explicit package relations against virtual packages, to 
    assess if some of them might benefit from being maintained as real 
    binary packages.

Here concretely, I just happened to do 2) and 3) together.

For comparison, some size benefit might be in decoupling 
node-types-babel-code-frame from node-babel7 - but in that case I am 
_required_ to do examination first, because the virtual package lack 
versioning and therefore cannot be declared explicitly in packages 
depending on it.  By not providing versioned virtual packages, it is 
harder to identify places beneficial for decoupling, because exact 
relationship cannot be declared ahead of the examination.


 - 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/c4704986/attachment.sig>