Am 24.10.19 um 19:58 schrieb Alexander Kanavin:
On Thu, 24 Oct 2019 at 19:45, Stefan Herbrechtsmeier
<[email protected] <mailto:[email protected]>> 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
--
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core
