[OE-core] [RFC][PATCH 0/6] NPM refactoring

[Stefan Herbrechtsmeier]

Am 24.10.19 um 19:58 schrieb Alexander Kanavin:
> On Thu, 24 Oct 2019 at 19:45, Stefan Herbrechtsmeier 
> <stefan at herbrechtsmeier.net <mailto:stefan at herbrechtsmeier.net>> wrote:
> 
>      > The package-lock.json in their tarball is 600K.
> 
>     The project use two major version and seven different versions with 30
>     installations of debug. Furthermore the dependencies include build
>     tools
>     which should not be installed on the device.
> 
>     The "@angular/cli" (242) and "node-red" (324) package share 106
>     packages.
> 
> 
> I have to ask: what point are you trying to make?

The both packages with different audience share between 44% and 33% of 
the packages. I think this true for other packages too.

> Here's a related lwn article describing a similar problem faced by opensuse:
> https://lwn.net/Articles/712318/

Unfortunately they also have no solution.

> ""Ruby dependency hell has nothing on JavaScript dependency hell," he 
> said. A "hello world" application based on one JavaScript framework has 
> 759 JavaScript dependencies; this framework is described as "a 
> lightweight alternative to Angular2".

Unfortunately they don't name the package nor give details about the 
dependencies. I assume they really count the dependencies with all there 
duplications and multiple minor or patch versions.


> There is no way he is going to 
> package all 759 dependencies for this thing; the current distribution 
> package-management approach just isn't going to work here."

What is the "current distribution package-management approach"? The 
manual creating of build configuration for every package or the 
automatic generation of recipes?

What is the alternative which fulfill the requirements of an embedded 
distribution?

My prototype automatically creates recipes from the packages. It only 
needs manual work if the package have no license file or a circular 
dependency.

The main problem is the pinning of specific versions inside the 
package.json and the increase of the major version if the support for a 
very old node.js version is removed.

The prototype assumes a compatible inside a major version and creates a 
recipe per major version. Thereby it always uses the latest version per 
major version. The recipe count could further optimized in a manual step 
which checks if there is really a breaking change between the major 
version. The number of this recipes is low in compare to the total count 
of recipes but the packages are often shared between different packages.

Regards
   Stefan