I think the supposed workflow with the new npm.class was to use 'devtool create' which would run some npm magic to to create a single recipe that has all of the npm-fetched dependencies inside SRC_URI. Have you tried that?
A layer with thousands of recipes seems totally intractable. Alex On Tue, 5 Oct 2021 at 14:48, Stefan Herbrechtsmeier < stefan.herbrechtsmeier-...@weidmueller.com> wrote: > Hi Richard, > > Am 05.10.2021 um 13:09 schrieb Richard Purdie: > > Thanks for bring this up, I've been wondering on the status of our npm > support. > > Do you know any npm users? > > > On Tue, 2021-10-05 at 12:04 +0200, Stefan Herbrechtsmeier wrote: > >> I must improve the npm support for our use cases but need some > >> fundamental decisions to proceed. I need to build express and angular > >> applications from git repositories. > >> > >> I have the following changes in my pipeline until now: > >> - Support npm packages with missing execute mode for directories > >> - Reduce command calls in npm run > >> - Add support for local tarball and local link sources > >> - Rework crunch license to recognize more variants > >> - Move known license checksums to CSV file > >> - Pass README as fallback to guess license if a license is missing > >> - Add support to pass build arguments to npm install > >> - Add support to run build scripts with native packages > >> - Parallelize the populate of the npm cache > >> > >> The build (install) of npm packages leads to problems because of old > >> versions in the dependency tree. For example, older versions of packages > >> are incompatible with the Node.js version and older versions of node-gyp > >> require Python 2. > > > > Hopefully over time the python2 issue should reduce and fade at least. > The > > node.js version is trickier. > > The current implementation works like an project with embedded external > dependencies. I both cases I have to patch the embedded dependencies or > replace them with external DEPENDS. > > >> I see three solutions to integrate npm packages: > >> - Build npm packages from the npm project outside of OE and only fetch > >> the data. > >> - Fork the npm project repository and fix everything inside the fork. > >> Use the fork direct or create patches from the fork to build inside OE. > >> - Create recipes per project and incompatible version to fix everything > >> in OE and reduce redundancy. > >> > >> The last solution keeps everything in OE and benefit from the existing > >> OE functions like download proxy as well as license, CVE and version > >> check. But it increases the initial costs and makes only sense if there > >> is an interest in an meta-nodejs layer. > > > > The latter solution sounds like the only really viable option from an OE > > perspective since we do need the proxy/CVE/license handling, it is a > huge part > > of our value and without it, it isn't really OE. > > The problem are the many different packages. An Angular project could > have more than 1000 different project. Thereby some dependencies only > differ in the version or needed only for development like a development > server or a unit test framework. > > > Creating a meta-nodejs layer isn't an issue if there are people willing > to look > > after it. > > Is a layer with more more than 1000 recipes thinkable? > > Regards > Stefan > > > >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#156646): https://lists.openembedded.org/g/openembedded-core/message/156646 Mute This Topic: https://lists.openembedded.org/mt/86089523/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
