Hi, On Thu, 2019-12-12 at 07:49 -0500, Jean-Marie LEMETAYER wrote: > Hi folks, > > I am currently trying to update/refactor the handling of the NPM packages. > [...] > Is it OK ? Any thought ? Any advice ?
Three questions occurred to me on that whole subject... Mostly based on the understanding that there are no recipes for the dependencies, only for the main package. Firstly: With your approach, can I force a different version of a dependency to be fetched? I.e. a versions different from what npm would do? Use case: Let's say an npm package A somewhere down in the chain of my own (recursive) dependencies pulls in version 1.2 of package B, but version 1.2 is unsuitable for use, e.g. licensing issue. An updated, compatible, but yet unreleased on npmjs.org version of package B exists (e.g. in github), with the licensing fixed. Can I pull in that alternative version using your approach, as I believe there is no recipe for package C if I understand right, i.e. no place to put the alternative URL. Secondly: Say I need to patch an npm package C somewhere down in the chain of my own (recursive) dependencies to fix an issue with package C. Can I do that, as again, I believe there is no recipe for package C where I could update SRC_URI to include my patch. Thirdly: Will it be possible to handle projects that use angular natively in yocto using your approach. E.g. have an angular-native recipe that will allow running ng build on the code I'm interested in? Cheers, Andre' PS: Points one and two work with my (updated) script that I had posted some weeks ago here. -- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
