Node.js: Add node 8 and npm 5 support

[ovaar]

[malikolivier]

Thanks for the update! Can you explain why you exclude npm from the build image in ca0417b1c77a8aebe05e95cf40bf55ea01114a1b?

This causes a QA error during package as the node_modules files as /usr/lib/node_modules is not included FILES.

What's more, let me just give my two cents. On a freshly installed ubuntu 16.04.3 (no GUI), I had to install a few packages for do_compile to succeed:

dpkg --add-architecture i386 && apt-get update
apt-get install lib32z1-dev libssl-dev:i386 gcc-multilib g++-multilib

I don't understand myself why I needed i386 headers, but I would get a linker error without them.

[ovaar]

ca0417b was for personal interest. I did not realize it would append to the pull request. I'll revert that commit.

[ovaar]

Can we finalize this pull request?

[aaronovz1]

I second that^

[ovaar]

all good?

[mbbauer]

Could we please merge this? The lts version of node has changed.

[ovaar]

@imyller We need you man!

[mitorn]

FYI: os.popen is deprecated (used in npm-base.bbclass) in python 2.6 and subprocess module should be used instead. Also, npm_get_version in npm-base.bbclass leaves file open which will produce warning during build.

I fixed this as below patch suggests:

diff --git a/classes/npm-base.bbclass b/classes/npm-base.bbclass
index b545225..b40f241 100644
--- a/classes/npm-base.bbclass
+++ b/classes/npm-base.bbclass
@@ -19,10 +19,6 @@ NPM_FLAGS ?= ""
 
 NPM_FLAGS_append_class-nativesdk = " --unsafe-perm"
 
-def npm_get_version():
-    import os
-    return os.popen("npm --v").read().split('.')
-
 # Target npm
 
 oe_runnpm() {
@@ -66,7 +62,8 @@ oe_runnpm() {
 
        export HOME="${NPM_HOME_DIR}"
 
-       if [ "${@npm_get_version()[0]}" = "5" ]; then
+
+       if [ "$(echo ${NPM_VERSION} | cut -d. -f1)" = "5" ]; then
                NPM_CACHE_CMD="verify"
        fi
 
@@ -128,7 +125,7 @@ oe_runnpm_native() {
 
        export HOME="${NPM_HOME_DIR_NATIVE}"
 
-       if [ "${@npm_get_version()[0]}" = "5" ]; then
+       if [ "$(echo ${NPM_VERSION} | cut -d. -f1)" = "5" ]; then
                NPM_CACHE_CMD="verify"
        fi
 

[uwburn]

Any news on pulling this in? Having the new LTS would be great!

[zonque]

Is this repository still actively maintained or should people be using some replacement?

[aaronovz1]

Doesn't seem to be very active apart from thirdparty contributors.

[zonque]

Which is okay. I'm just wondering whether this is still the official nodejs layer repo, given that this PR is pending since 8 month.

[aaronovz1]

I maintain a fairly up to date PR and fork of this repo. Other than that the author of this repo has gone quiet for some time.

[ovaar]

+1

[ovaar]

@zonque there is no 'official' nodejs layer. This is the one though. Perhaps the author can authorization some other participants for maintaining this repository.

[mitorn]

There is some support for nodejs in openembedded-core. npm class seems to be quite much the same as in here. Also, devtool is supporting npm packages at least for some extent. I am investigating currently if i could start using devtool and openembedded-core npm class.

[deinok]

Guys, should we contact Node.js Foundation in order to create an oficial layer?

[keeslinp]

@mitorn Did your investigations have any success?

[bachp]

@mitorn The npm.bbclass in core use the bitbake fetcher to fetch all dependency. To use it devtool is pretty much a must as otherwise the dependency management is way to much work.

The classes in this layer are much simpler and they rely on npm to fetch everything. They do not use the bitbake fetcher mechanism and thus you can't cache/archive the downloads the way you normally do with bitbake. An "advantage" is that you do not need to specify all the dependency at the bitbake level. This might be easier in some cases especially when used with a local npm mirror.

@deinok Is there a need for a seperate layer. The latest LTS (8.x) version is also available in meta-openembedded. If somebody would be willing to maintain it I think it would also be possible to have the Latest (10.x) available as a recipe too.

[mitorn]

@keeslinp we haven't had time lately to test devtool based npm fetcher. It would be quite feasible for us since it does bitbake license management instead of creating your own. There was open questions at least about locking commits (can we trust package-lock-.json for example).

@bachp we would like to use devtool because of the license handling which i think this layer does not provide.