AWS Lambda – Some Important Changes I’d Like To See

Recently we updated our open source project Auto Tag, a Lambda function that listens to CloudTrail to tag your AWS resources with their creator after they are created. When updating, I noticed that a month ago, AWS released a Node v4.3.2 runtime for AWS Lambda. I was super excited! Previously we were using babel to transpile our ES6 source code to ES5 such that it could run in the Node v0.10 runtime previously available (still supported). Surely this update meant that I could scrap transpiling my source code and start running ES6 natively.

Unfortunately not.

Node v4 is not ES6 complete. The website Node Green, which has a nice ES6 feature compatibility table, puts the current long term support (LTS) version of Node, v4.4.4 (beyond v4.3.2 offered by AWS Lambda) at 47% ES6 completeness. Two of the ES6 features that we use extensively this is missing in this version are the new ES6 import/export module syntax and the class statement. This meant that we would need to continue using babel to transpile our code to ES5 such that it could reliably run on v4.3.2.

So, a couple of asks for the AWS Lambda team if they ever read this post:

1. Please support a node version for LTS (v4.4.4), Stable (v5.11.1) and Current (v6.1.0). This would make it way easier for developers to write future proof, modern JavaScript without having to transpile their code before deployment.
2. Please add some mechanism to define environment variables for my Lambda functions. Right now I don’t have an elegant way to separate my configuration from my code, meaning that each configuration change requires a rebuild and redeploy. Something similar to the environment variable configuration for Elastic Beanstalk or ECS containers would be great!

Just my thoughts. Anyone else out there using Node.js on Lambda? Would love to hear your thoughts on our slack channel!