Runtime.UserCodeSyntaxError: SyntaxError: Unexpected token

What it means

Parsing happens before execution. When Lambda initialises a Node function it reads the handler file and hands it to the parser, and a file that cannot be parsed produces no exports, no side effects, and no log lines — the runtime never gets far enough to run the first statement. Runtime.UserCodeSyntaxError is that failure, reported by the runtime on your behalf.

The instinctive reading is "I deployed a typo", and occasionally that is exactly right. But on Lambda specifically, the majority of these are not syntax errors in any meaningful sense. They are the CommonJS parser being handed ESM syntax, or the ESM parser being handed CommonJS. Both produce a genuine SyntaxError — Cannot use import statement outside a module is the best-known phrasing — and neither indicates anything wrong with the code. The code is valid; it is being parsed by the wrong grammar.

Which grammar runs is decided by two things: the file extension, and the type field in the nearest package.json. .mjs is always ESM, .cjs is always CommonJS, and a plain .js file takes whichever the type field says, defaulting to CommonJS. A local dev server, a test runner or a bundler frequently papers over a mismatch by transpiling on the fly, which is why this class of failure has a habit of appearing for the first time in a deployed environment.

The other recurring shape is an artifact that does not contain what you think. If the error names syntax your build step is supposed to remove — a type annotation, JSX, an enum — then the deployment package contains source rather than compiled output, and the packaging step is collecting the wrong directory. That is worth checking early, because no amount of reading the source will explain an error that comes from a file you never intended to ship.

What it looks like in CloudWatch

This is the shape the failure arrives in: the lines of one invocation scattered among everything else the log group received at the same moment.

The panel on the right is generated by running the excerpt on the left through the same parser that powers the free web stitcher — it is what the tool actually produces for this input, not an illustration of it.

How to confirm it from the logs

The message carries the underlying SyntaxError and, in the stack, the file and position where the parser gave up. It arrives immediately after INIT_START with none of your own output before it, because the file never finished loading. Error Type: Runtime.UserCodeSyntaxError appears on the REPORT line where the runtime writes it.

Read the specific SyntaxError text rather than stopping at the wrapper. Cannot use import statement outside a module and Unexpected token 'export' are not typos at all — they are the CommonJS parser meeting ESM syntax, which is a configuration problem. A genuine typo usually reads as Unexpected token at a position that matches something you recently edited.

Causes, most likely first

Fixes

json{
  "name": "orders-function",
  "type": "module",
  "engines": { "node": ">=22" }
}

bash# Parse without executing — non-zero exit on a syntax error.
node --check dist/index.js

# And confirm the artifact holds build output, not source.
unzip -l function.zip | grep -E '\.(ts|tsx|jsx)$' && echo "source leaked into the package"

bashnpx esbuild src/index.ts \
  --bundle --platform=node \
  --target=node22 \
  --format=esm \
  --outfile=dist/index.mjs

Also seen as

The same underlying failure, worded differently by a different runtime, SDK version, or logging layer. All of these land here — there is no separate page for each phrasing.

Related errors

Errors that show up alongside this one, or that people mistake for it.

References

• AWS Lambda Developer Guide — Define Lambda function handler in Node.js
• Node.js — Modules: Packages