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

[Xavier]

Le 03/12/2020 à 19:05, Jonas Smedegaard a écrit :
> 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.

node-babel7 does provide versioned virtual packages (like acorn). I'll
study if node-babel7 can be split into multiple packages. It took me
around 4 hours to split jest correctly...

Done for jest, waiting for ftpmaster review.

Cheers,
Xavier