Fixes and improvements for current AWS-provided Node runtimes by ScottMorse · Pull Request #155 · arithmetric/aws-lambda-ses-forwarder

ScottMorse · 2026-04-06T20:57:42Z

Issues

Fixes (#154)

Main issues

The latest AWS-provided Node 24 runtime no longer supports the callback-based handler used currently, requiring async handlers instead. Async handlers have been supported since 2018 and are supported on all provided runtimes. AWS Docs: Valid handler patterns for Node.js functions
For users copying the contents of index.js into the Lambda console for a quick setup, Lambda now defaults to using index.mjs, so the CJS syntax breaks unless one knows to update the handler filename.
- ESM syntax is now highly encouraged in Lambda and Node in general and would make use of this code smoother for all the current supported Node runtimes, which are 20, 22, and 24. ESM syntax has been supported in Lambda since the Node 14 runtime.

Related/secondary issues

Lambda looks at the handler function .length to detect a callback vs. async handler, so the overrides must be split from the main async handler function in addition to dropping the callback param.
ESM syntax isn't very friendly with nyc for tests
The version logged at the top of index.js is inaccurate from being hard-coded from a previous version

Solutions

Update index.js functions to be async arrow functions as the fix for Node 24
Use createHandler to split overrides param out of handler
- Lambda reads handler.length to detect callback vs. async handler use, so it will still throw a deprecation error in Node 24 without this, even if correctly using the async pattern.
Update example to use createHandler
Update tests
- Use async syntax for updated index.js functions
- Use createHandler for overrides
- Preserve original intent as closely as possible
- Minor change to impl of final handler.js test to use explicitly rejected Promise, instead of causing unobvious TypeError via next().
Use ESM syntax
- Update index.js, example/, and tests/ imports and exports
- Add "type": "module" to package.json
- Switch sourceType to "module" in ESLint config
- Remove "use strict" since this is the default for ESM
Switch to c8 for tests instead of nyc
- ESM-friendly with similar features
- Updated package.json scripts to approximate old nyc usage
Upgrade AWS SDK dependencies (will match what is available by default on a Lambda instance more closely)
Fix console.log in index.js to reflect current package version (would need to be updated again on version bump)

Notes

I'm using this code currently with Node 24
Tests and lint pass for me locally
I've manually tested this with the two other supported runtimes, Node 20 and 22
While ESM has been around for a while and is encouraged by Lambda, this could break CJS users of the library. I'd argue the best solution overall might be to add something like a build step that can output CJS from the raw ESM for maximum compatibility, but since I bit off a lot just with this PR, I did not want to tackle something like this at the moment.

…eprecation error

brandonbothell

Shouldn't you rename index.js to index.mjs?

ScottMorse · 2026-04-17T18:31:46Z

@brandonbothell Since package.json would now have "type": "module", index.js is treated as ESM already. It would reflect what users see in the Lambda editor in the AWS console a bit more to change the name if they're using a copy+paste setup, but it would mostly be an aesthetic change. Up to you. It would just mean changing the file name and updating the "main" field in package.json.

brandonbothell · 2026-04-17T18:35:49Z

Thank you for the info, I believe that since it's recommended in the README as a possible installation method, we should aim to support the copy+paste method with as minimal user-confusion as possible.

…runtime versions)

ScottMorse · 2026-04-17T18:52:45Z

@brandonbothell Makes sense! I went ahead and performed the update:

file name change
"main" field change in package.json
README and comment in example now refer to index.mjs instead of index.js
ESLint config covers .mjs
Tests needed import statements updated

I also just noticed that the README lists Node 18, 20 and 22 as the current Lambda runtimes, so I updated this to 20, 22 and 24, and the lint-test github workflow similarly runs against Node 18, 20, and 22, so I updated that as well.

brandonbothell · 2026-04-17T19:27:24Z

+  "main": "index.mjs",
  "scripts": {
    "check-coverage": "c8 report --reporter=lcov && c8 check-coverage --statements 100",
    "lint": "npx eslint",


Should this be updated to npx eslint@^9.18.0 (or we can update dependencies?)

Oh, npx is actually redundant here. package.json scripts have node_modules/.bin in their PATH, which is why you can invoke dependencies' executables there directly.

npx will similarly use node_modules/.bin if it's present from the cwd. If npx is called and the command isn't found in node_modules/.bin, that's when it installs the latest version of a package dynamically (or uses its cache) to run it.

So in this instance, npx eslint is no different than plain eslint within "scripts".

The "eslint" package is installed as a peer dependency of the other ESLint-related packages, which supplies the eslint command and may differ in version from @eslint/js.

I am seeing now that when I delete my package-lock.json and run npm install, it downloads eslint at version 10.2.0, so running npx eslint --version in the repo then reports v10.2.0 to me, the same as if I run npm run lint -- --version regardless of whether npx eslint or eslint is used in the package.json script.

However, version 10 doesn't seem to be working with the plugins being used, so it's probably worth locking down the version of "eslint" to use to that it's not up to chance anymore. I can make a simple change for all this.

Yeah, this makes sense as why I had to pin the npx command @^9.18.0. Thanks again for the useful info, your suggestion sounds good!

No problem! I author a package that has a CLI for Bun, and package.json, node_modules/.bin, and bunx (the npx equivalent) work essentially the same way, which is the only reason I actually understand how this stuff works.

I went ahead and made the package.json changes for this, just setting the "eslint" version and simplifying the script to eslint.

brandonbothell · 2026-04-17T21:00:32Z

That makes a lot of sense! In the back of my mind, while I was replying earlier, I wondered if the original author did use `npx` for a reason. Is it possible that if a user has a global installation of `eslint` in their path above NPM's that isn't compatible with the project's dependencies, that just having `eslint` in the script could cause issues?

…

On Fri, Apr 17, 2026 at 4:28 PM Scott Morse ***@***.***> wrote: ***@***.**** commented on this pull request. ------------------------------ In package.json <#155?email_source=notifications&email_token=AIRI62QCINGQLBIJN22UNPT4WKHWBA5CNFSNUABKM5UWIORPF5TWS5BNNB2WEL2QOVWGYUTFOF2WK43UKJSXM2LFO4XTIMJTGE4TANJTGEYKM4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJL3QOJPXEZLWNFSXOX3DNRUWG2Y#discussion_r3103080398> : > @@ -3,7 +3,7 @@ "version": "6.0.0", "description": "Serverless email forwarding using AWS Lambda and SES", "type": "module", - "main": "index.js", + "main": "index.mjs", "scripts": { "check-coverage": "c8 report --reporter=lcov && c8 check-coverage --statements 100", "lint": "npx eslint", No problem! I author a package that has a CLI for Bun, and package.json, node_modules/.bin, and bunx (the npx equivalent) work essentially the same way, which is the only reason I actually understand how this stuff works. I went ahead and made the package.json changes for this, just setting the "eslint" version and simplifying the script to eslint. — Reply to this email directly, view it on GitHub <#155?email_source=notifications&email_token=AIRI62VZLQY3IHLHWDAOWC34WKHWBA5CNFSNUABKM5UWIORPF5TWS5BNNB2WEL2QOVWGYUTFOF2WK43UKJSXM2LFO4XTIMJTGE4TANJTGEYKM4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJPLQOJPXEZLWNFSXOX3ON52GSZTJMNQXI2LPNZZV6Y3MNFRWW#discussion_r3103080398>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AIRI62TCQ5Z4ARW2SJUMRPD4WKHWBAVCNFSM6AAAAACXOTVKLKVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHM2DCMZRHEYDKMZRGA> . You are receiving this because you were mentioned.Message ID: ***@***.*** com>

ScottMorse · 2026-04-17T21:15:59Z

@brandonbothell I don't think that's the case. npx eslint still defaults to node_modules/.bin/eslint regardless of whether a global install of eslint is present. When you use npm i -g eslint, you do have the eslint executable on your user's PATH, but the node_modules/.bin path still takes precedence over that for both npx or the plain eslint script.

I have a feeling it's probably just that the author used npx eslint to run it before adding the script in package.json and didn't realize or forgot that it's unnecessary.

brandonbothell · 2026-04-17T21:19:18Z

Thanks for the explanation. I think this PR is good to go when/if the maintainer is ready to merge it then.

…

On Fri, Apr 17, 2026 at 5:16 PM Scott Morse ***@***.***> wrote: *ScottMorse* left a comment (arithmetric/aws-lambda-ses-forwarder#155) <#155?email_source=notifications&email_token=AIRI62RAREUKCFDJK7OV5IT4WKNKLA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIMRXGEZTIMBZGE4KM4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJNLQOJPWG33NNVSW45C7N5YGK3S7MNWGSY3L#issuecomment-4271340918> @brandonbothell <https://github.com/brandonbothell> I don't think that's the case. npx eslint still defaults to node_modules/.bin/eslint regardless of whether a global install of eslint is present. When you use npm i -g eslint, you do have the eslint executable on your user's PATH, but the node_modules/.bin path still takes precedence over that for both npx or the plain eslint script. I have a feeling it's probably just that the author used npx eslint to run it before adding the script in package.json and didn't realize or forgot that it's unnecessary. — Reply to this email directly, view it on GitHub <#155?email_source=notifications&email_token=AIRI62RAREUKCFDJK7OV5IT4WKNKLA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIMRXGEZTIMBZGE4KM4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJNLQOJPWG33NNVSW45C7N5YGK3S7MNWGSY3L#issuecomment-4271340918>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AIRI62REXJJDADSRQS4EYML4WKNKLAVCNFSM6AAAAACXOTVKLKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DENZRGM2DAOJRHA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

ScottMorse added 13 commits April 6, 2026 12:02

Use modern ESM syntax for main module

69edd09

Update example to use ESM syntax

dd07208

Update ESLint config for ESM syntax

f87a71b

Upgrade AWS sdk packages

e32013a

Update tests to use ESM imports

a867b0c

Fix index.js style lint error

378504c

Fix json import in index.js

d60e66e

Update tests to use c8 for ESM compatibility

b20b963

Improve async syntax

979bedd

Update tests with async patterns

b7b3a1b

Use createHandler to get around AWS reading function.length causing d…

788b18a

…eprecation error

Simplify version log with current version

e3712ca

Better ESLint handling

1d6788c

ScottMorse mentioned this pull request Apr 6, 2026

Works in Node.JS 22, but NOT on Node.JS 24 on AWS Lambda #154

Open

This comment was marked as outdated.

Sign in to view

brandonbothell suggested changes Apr 17, 2026

View reviewed changes

ScottMorse added 6 commits April 17, 2026 12:41

Change main file from index.js to index.mjs

eff1924

Update eslint config to cover .mjs

af4b7a4

Update README and example references to index.js to index.mjs

b36beb9

Update tests to import index.mjs

22e1ee4

Update README with current Node runtime versions

5b83b18

Update lint-test workflow to use Node 20, 22, and 24 (current Lambda …

b47af65

…runtime versions)

brandonbothell reviewed Apr 17, 2026

View reviewed changes

brandonbothell mentioned this pull request Apr 17, 2026

Specify eslint version ScottMorse/aws-lambda-ses-forwarder#1

Closed

Set eslint dep version and simplify lint script

a426fed

brandonbothell approved these changes Apr 17, 2026

View reviewed changes

Navigation Menu

Fixes and improvements for current AWS-provided Node runtimes - #155

Fixes and improvements for current AWS-provided Node runtimes#155
ScottMorse wants to merge 20 commits into
arithmetric:masterfrom
ScottMorse:master

ScottMorse commented Apr 6, 2026 •

edited

Loading

Uh oh!

This comment was marked as outdated.

Uh oh!

brandonbothell left a comment

Uh oh!

ScottMorse commented Apr 17, 2026

Uh oh!

brandonbothell commented Apr 17, 2026 via email •

edited

Loading

Uh oh!

ScottMorse commented Apr 17, 2026

Uh oh!

brandonbothell Apr 17, 2026

Uh oh!

ScottMorse Apr 17, 2026

Uh oh!

brandonbothell Apr 17, 2026

Uh oh!

ScottMorse Apr 17, 2026

Uh oh!

brandonbothell commented Apr 17, 2026 via email

Uh oh!

ScottMorse commented Apr 17, 2026

Uh oh!

brandonbothell commented Apr 17, 2026 via email

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Conversation

ScottMorse commented Apr 6, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Issues

Main issues

Related/secondary issues

Solutions

Notes

Uh oh!

This comment was marked as outdated.

Uh oh!

brandonbothell left a comment

Choose a reason for hiding this comment

Uh oh!

ScottMorse commented Apr 17, 2026

Uh oh!

brandonbothell commented Apr 17, 2026 via email • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ScottMorse commented Apr 17, 2026

Uh oh!

brandonbothell Apr 17, 2026

Choose a reason for hiding this comment

Uh oh!

ScottMorse Apr 17, 2026

Choose a reason for hiding this comment

Uh oh!

brandonbothell Apr 17, 2026

Choose a reason for hiding this comment

Uh oh!

ScottMorse Apr 17, 2026

Choose a reason for hiding this comment

Uh oh!

brandonbothell commented Apr 17, 2026 via email

Uh oh!

ScottMorse commented Apr 17, 2026

Uh oh!

brandonbothell commented Apr 17, 2026 via email

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

ScottMorse commented Apr 6, 2026 •

edited

Loading

brandonbothell commented Apr 17, 2026 via email •

edited

Loading