'devtool add' of course. Test case is in meta/lib/oeqa/selftest/cases/devtool.py
Alex On Tue, 5 Oct 2021 at 15:10, Alexander Kanavin via lists.openembedded.org <[email protected]> wrote: > 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 < > [email protected]> 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 (#156647): https://lists.openembedded.org/g/openembedded-core/message/156647 Mute This Topic: https://lists.openembedded.org/mt/86089523/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
