[OE-core] [RFC][PATCH 1/6] npm.bbclass: refactor the npm class

Jean-Marie LEMETAYER jean-marie.lemetayer at savoirfairelinux.com
Thu Oct 24 15:13:18 UTC 2019


Hi Stefan,

On Oct 24, 2019, at 1:22 PM, Stefan Herbrechtsmeier stefan at herbrechtsmeier.net wrote:
> Am 22.10.19 um 11:03 schrieb Jean-Marie LEMETAYER:
>> Many issues were related to npm dependencies badly handled: package
>> names, installation directories, ... In fact npm is using an install
>> algorithm [1] which is hard to reproduce / anticipate.
> 
> Why do you think it is hard to reproduce?

The previous npm support tried to manage dependencies manually. But it could easily fail. My goal with this refactoring is to actually be able to _use_ npm recipes.

I remember that you are working on a npm refactoring too, but using one recipe per package and handling dependencies using RDEPENDS. To me this will generate a lot of work to create the recipes. For instance a basic angular application gathers more than thousands of dependencies and thus would lead to thousands of recipes. The work needed to create and maintain all those recipes is huge.

>> Moreover some
>> npm packages use scopes [2] which adds more complexity.
> 
> The addition complexity is limited.

You are right but this case was not handled in the previous npm support and is now supported.

>> The simplest solution is to let npm do its job. Assuming the fetcher
>> only get the sources of the package, the class will now run
>> 'npm install' to create a build directory. The build directory is then
>> copied wisely to the destination.
> 
> You use an full-blown package manager which total different design goals
> and no understanding for embedded / restricted systems.

This patchset save more memory space on the target than the actual implementation as all the build artifacts are removed. So I believe that it is suitable for embedded restricted systems.

>> +    # Finally install and build the tarball package in ${B}.
>> +    local NPM_INSTALL_ARGS="${NPM_INSTALL_ARGS} --loglevel silly"
>> +    local NPM_INSTALL_ARGS="${NPM_INSTALL_ARGS} --prefix=${B}"
>> +    local NPM_INSTALL_ARGS="${NPM_INSTALL_ARGS} --global"
>> +
>> +    if [ "${NPM_INSTALL_DEV}" != 1 ]
>> +    then
>> +        local NPM_INSTALL_ARGS="${NPM_INSTALL_ARGS} --production"
>> +    fi
>> +
>> +    local NPM_INSTALL_GYP_ARGS="${NPM_INSTALL_GYP_ARGS} --arch=${NPM_ARCH}"
>> +    local NPM_INSTALL_GYP_ARGS="${NPM_INSTALL_GYP_ARGS}
>> --target_arch=${NPM_ARCH}"
>> +    local NPM_INSTALL_GYP_ARGS="${NPM_INSTALL_GYP_ARGS} --release"
>> +
>> +    cd ${WORKDIR} && npm install \
> 
> Why you don't use "npm ci"?

Thanks for the tips, I did not know about the 'npm ci' command. Sadly it fails to handle '--global' installation. The 'npm pack && npm install' trick is much more efficient as explain in this commit:
  https://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=d38e1e2c2ea4646b34ea6282d3d7620df5b0374b

Regards,
Jean-Marie


More information about the Openembedded-core mailing list