node 16 support

[vishal550]

by when it will support node 16

[daniel-gato]

Same interest here

[USSliberty]

Same here, no commits since July, last release on 2021, project abandoned? (hope not)

[realityfilter]

The current release just crashes with nodejs-16 on alpine linux. Would be great to have a compatible version.

[tonmaz]

Same interest here

[softgripper]

Same interest here.

I got an email from Amazon telling me to upgrade my lambdas to node 16... and then am met with this.

[dsoyez]

image doesn't build with node:16
any update ? Looks like this project is dead

[esamattis]

Duplicate. See #41 (comment)

[fadams]

For what it's worth although it doesn't seem to build with the node:16-buster or node:18-buster images it does seem to build with Node.js installed via the binary archive so, for example I did the following where the first stage build-image differs from the docs in this repo, but the second stage is largely the same:

FROM debian:buster as build-image

RUN apt-get update && \
    apt-get install -y \
    ca-certificates curl \
    make cmake autoconf automake libtool \
    libcurl4-openssl-dev g++ python3 && \
    # --------------------------------------------------------------------------
    # Install LTS Node.js via binary archive
    # https://github.com/nodejs/help/wiki/Installation
    VERSION=v16.16.0 ARCH=linux-x64 DISTRO=node-${VERSION}-${ARCH} && \
    curl -sSL https://nodejs.org/dist/${VERSION}/${DISTRO}.tar.gz | \
    tar -xzv -C /usr/local/bin/ && \
    # symlink the Node.js binaries to a sane location
    ln -s /usr/local/bin/${DISTRO}/bin/node /usr/local/bin/node && \
    ln -s /usr/local/bin/${DISTRO}/bin/npm /usr/local/bin/npm && \
    ln -s /usr/local/bin/${DISTRO}/bin/npx /usr/local/bin/npx && \
    # Build and install Lambda Runtime Interface Client for Node.js via npm
    cd /usr/local/lib && \
    npm install aws-lambda-ric

FROM node:16-buster-slim

ENV LAMBDA_TASK_ROOT=/usr/local/lib

COPY --from=build-image ${LAMBDA_TASK_ROOT} ${LAMBDA_TASK_ROOT}
COPY lambda-entrypoint.sh /
COPY echo.js ${LAMBDA_TASK_ROOT}

WORKDIR ${LAMBDA_TASK_ROOT}

ENTRYPOINT ["/lambda-entrypoint.sh"]
CMD ["echo.handler"]

and for Node.js 18

FROM debian:buster as build-image

RUN apt-get update && \
    apt-get install -y \
    ca-certificates curl \
    make cmake autoconf automake libtool \
    libcurl4-openssl-dev g++ python3 && \
    # --------------------------------------------------------------------------
    # Install LTS Node.js via binary archive
    # https://github.com/nodejs/help/wiki/Installation
    VERSION=v18.15.0 ARCH=linux-x64 DISTRO=node-${VERSION}-${ARCH} && \
    curl -sSL https://nodejs.org/dist/${VERSION}/${DISTRO}.tar.gz | \
    tar -xzv -C /usr/local/bin/ && \
    # symlink the Node.js binaries to a sane location
    ln -s /usr/local/bin/${DISTRO}/bin/node /usr/local/bin/node && \
    ln -s /usr/local/bin/${DISTRO}/bin/npm /usr/local/bin/npm && \
    ln -s /usr/local/bin/${DISTRO}/bin/npx /usr/local/bin/npx && \
    # Build and install Lambda Runtime Interface Client for Node.js via npm
    cd /usr/local/lib && \
    npm install aws-lambda-ric

FROM node:18-buster-slim

ENV LAMBDA_TASK_ROOT=/usr/local/lib

COPY --from=build-image ${LAMBDA_TASK_ROOT} ${LAMBDA_TASK_ROOT}

COPY lambda-entrypoint.sh /

COPY echo.js ${LAMBDA_TASK_ROOT}

WORKDIR ${LAMBDA_TASK_ROOT}

ENTRYPOINT ["/lambda-entrypoint.sh"]
CMD ["echo.handler"]

This was with a trivial echo lambda

"use strict";

exports.handler = async (event, context) => {
    return event;
}

One other thing I observed is that with Node 16 and 18 npx seems to launch less "cleanly", there seems to be a sh -c rather than directly execing node, so I observed aws-lambda-ric starts fine, but segfaults (or the launcher does) if its HTTP connection is disconnected. That doesn't happen if aws-lambda-ric is run directly with node, so my lambda-entrypoint.sh looks like this:

#!/bin/sh
if [ $# -ne 1 ]; then
  echo "entrypoint requires the handler name to be the first argument" 1>&2
  exit 142
fi

if [ -z "${AWS_LAMBDA_RUNTIME_API}" ]; then
  #exec /usr/local/bin/aws-lambda-rie /usr/local/bin/npx aws-lambda-ric "$1"
  exec /usr/local/bin/aws-lambda-rie node /usr/local/lib/node_modules/.bin/aws-lambda-ric "$1"
else
  #exec /usr/local/bin/npx aws-lambda-ric "$1"
  exec node /usr/local/lib/node_modules/.bin/aws-lambda-ric "$1"
fi

Hopefully this is useful and helps give folks an approach that lets them continue to use the official node node:16-buster or node:18-buster images.

As has been pointed out elsewhere it's also possible to "kidnap" the aws-lambda-ric from the official AWS base images. That actually appears somewhat different to the aws-lambda-ric in this repo, though that may be superficial/packaging differences. Like others here I think AWS should at least give a heads-up/ETA of when up to date versions of Node.js will be properly supported, especially as the official AWS images are kind of large......

HTH

[faazshift]

@fadams I managed to make the "kidnap" option work (pretty well so far) for Node 18. Given my unique needs, that turned out to be the best option. It's unfortunate AWS support has been so lacking.

Anyhow, if it's helpful to anyone else, this was my multi-stage Dockerfile:

FROM public.ecr.aws/lambda/nodejs:18 as lambda-image

FROM node:18

RUN ln -sf bash /bin/sh
RUN mkdir /var/task
WORKDIR /var/task

RUN apt-get update && \
    apt-get install -y \
    g++ \
    make \
    cmake \
    unzip \
    libcurl4-openssl-dev \
    autoconf \
    libtool \
    libtool-bin

ENV LAMBDA_RUNTIME_DIR=/var/runtime
ENV LAMBDA_TASK_ROOT=/var/task

RUN mkdir /var/lang
RUN ln -s /usr/local/bin /var/lang/bin

COPY --from=lambda-image /lambda-entrypoint.sh /lambda-entrypoint.sh
COPY --from=lambda-image /var/runtime /var/runtime
COPY --from=lambda-image /usr/local/bin/aws-lambda-rie /usr/local/bin/aws-lambda-rie

ADD . .
RUN npm i

ENTRYPOINT ["/lambda-entrypoint.sh"]
CMD ["index.handler"]

[andclt]

Hi,

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

Summary of the issue:
Starting from npm@8.6.0, 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