Update to a newer node versions

[jimmywarting]

Some packages use newer features that are not available in your NodeJS version, I where just wondering if you could update it to a newer version.

[USSliberty]

+1 for this thing
BTW We are using this package with Node 16.13.2 (16.13.2-alpine3.15) since January 2022 and no problems so far.

[gregorymfoster]

++

[kiduko]

For me, It is not work after Node 16.14.2.
After 16.14.2(such as 16.14.3), AWS lambda always return below error.
Error: Runtime exited with error: exit status 254 Runtime.ExitError

[zejji]

Any news on this from the AWS team? NodeJS 18 will become the active LTS in October 2022, so the RIC support is getting very out-of-date.

[USSliberty]

Please can you give us an ETA? It is really, really old at this point.

[jimmywarting]

Would be really nice if you could install the requested node version provided by pacakge.json or something like that...

  "engines": {
    "node": "-----"
  }

[pbadenski]

Any news?! This library still only supports Node 14 - which is in Maintenance phase since 1 year and 2 even-numbered versions behind current LTS.

The fact that noone from AWS responded to this ticket yet is shockingly unprofessional and shows major disregard for their customer base.

[makeable]

I contacted AWS support about this a few days ago. They said the lambda team are aware of the issue and are working on it (although quite why they havent responded here...)

They said that as a workaround, you can extract the runtime from the official amazon images with the following command:

docker run --entrypoint /bin/bash public.ecr.aws/lambda/nodejs:16 -c 'yum install -y tar gzip &>/dev/null && tar czf - /var/runtime' | tar xzf -

Note that the included aws-sdk module that gets extracted is not required for the runtime to work.

[DavidArayan]

Is there any news on this? Amazon officially supports NodeJS 18 however the RIC has yet to be updated. We rely on this module to run our own base images on Lambda.

@makeable Did you manage to get the workaround executing? We get errors related to missing libraries etc when trying to run with NodeJS 18 using following command.

docker run --entrypoint /bin/bash public.ecr.aws/lambda/nodejs:18 -c 'yum install -y tar gzip &>/dev/null && tar czf - /var/runtime' | tar xzf -

[esamattis]

@DavidArayan

We get errors related to missing libraries etc when trying to run with NodeJS 18 using following command.

What base image are you using? If you are using an Alpine Linux based one it could be because it's using musl libc and the aws image is using glibc. So try 18-slim instead of 18-alpine for example. IRC the slim image uses Debian and thus glibc.

We'll need to figure out a solution / workaround for this too as Node.js 14 goes of end life very soon.

[DavidArayan]

@esamattis

What base image are you using? If you are using an Alpine Linux based one it could be because it's using musl libc and the aws image is using glibc.

We tried a variety of base images including 18-slim. Perhaps we're doing something wrong with the setup. Is there a list of libraries besides glibc that the RIC relies on that we are missing?

[esamattis]

Uh. So yeah. We ported our custom image to use the provided base image. It seems to be very actively updated.

It has yum which can be used to add custom packages very easily. The only downside is that the image size more than doubled from our previous Alpine based one. Will probably look into SlimToolkit for reducing it's size at some point.

[andclt]

Hi,

We investigated the issue and have updated instructions on how to use the RIC with Node16+.

Summary of the issue:
Starting from [email protected], npm writes logs under the /home/.npm dir: npm/cli#4594
This is not possible inside the Lambda execution env since the fs is read-only. In earlier versions of npm, there was a bug which caused it to silently fail when unable to write cache directory: npm/cli#4996, hence why the runtime was just returning the 254 error code. There are some ways to prevent this:

1. (preferred) Setting the npm cache folder path to /tmp using a Docker ENV var:

ENV NPM_CONFIG_CACHE=/tmp/.npm

2. Use yarn instead of npm since it fallbacks to /tmp if the preferred cache folder isn't writable
3. Setting ENV NPM_CONFIG_CACHE=/tmp/.npm inside Lambda as an env var
4. Run aws-lambda-ric directly using node instead of using npx