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