`@smithy/core` version 3.24.0 "ReferenceError: crypto is not defined" in serde UUID v4 fallback on Node 18

[wpessers]

Noticed this in CI of opentelemetry-js-contrib only for node 18:

ReferenceError: crypto is not defined
      at Object.v4 (/home/runner/work/opentelemetry-js-contrib/opentelemetry-js-contrib/node_modules/@smithy/core/dist-cjs/submodules/serde/index.js:445:5)
      at /home/runner/work/opentelemetry-js-contrib/opentelemetry-js-contrib/node_modules/@smithy/core/dist-cjs/submodules/retry/index.js:165:63
      at async /home/runner/work/opentelemetry-js-contrib/opentelemetry-js-contrib/node_modules/@aws-sdk/middleware-sdk-sqs/dist-cjs/index.js:88:18
      at async /home/runner/work/opentelemetry-js-contrib/opentelemetry-js-contrib/node_modules/@aws-sdk/middleware-logger/dist-cjs/index.js:5:26
      at async Context.<anonymous> (test/aws-sdk-v3-sqs.test.ts:70:22)

Did some digging and came to following conclusion:

The v4 uuid generator in serde/uuid/v4.ts has always had a fallback using the global crypto without a guard, but on node it use to be dead code: randomUUID.ts used import * as crypto from "node:crypto" so randomUUID was always defined and v4 always took the fast path. #2009 replaced the node-specific import with a runtime typeof crypto check:

smithy-typescript/packages/core/src/submodules/serde/uuid/randomUUID.ts

Lines 1 to 4 in bf13524

	export const randomUUID =
	typeof crypto !== "undefined" && typeof crypto.randomUUID === "function"
	? (crypto.randomUUID.bind(crypto) as typeof crypto.randomUUID)
	: undefined;

So that means the fallback will be hit whenever globalThis.crypto isn't on the global object, which is the case in node 18 (where it sits behind a feature flag --experimental-global-webcrypto). node 18 is currently the package's minimum engine version:

smithy-typescript/packages/core/package.json

Lines 168 to 170 in bf13524

	"engines": {
	"node": ">=18.0.0"
	},

But this breaks every node 18 consumer of any AWS SDK call that needs an idempotency token.

[kuhe]

Thanks for reporting this issue. I confirm the bug is a coding error on my part. We intend for the package to continuing working with older Node.js-18 supporting clients.

I plan to release a patch later today.

I've opened a fix PR in #2023.

However, I can't publish it quite yet. Due to an incident detailed on the AWS Health Dashboard and temporary hold on publishing, we will delay the release of this patch by a few days.

---

As a temporary workaround, please try one of the following:

• use the previous working set of dependency versions
• OR, upgrade your Node.js runtime to a LTS version such as Node.js v22 (recommended)
• OR, manually import node:crypto and set it on the global scope.

[wpessers]

Cool, thanks for the quick fix @kuhe!

[kuhe]

released in https://www.npmjs.com/package/@smithy/core/v/3.24.1

[kuhe]

@wpessers why did the original test fail?

This ref https://nodejs.org/docs/latest-v18.x/api/crypto.html#cryptogetrandomvaluestypedarray says node:crypto getRandomValues is available in v18.

Based on using mise to install various versions of Node.js, the global crypto getRandomValues appears to be available in node 18 without the --experimental-global-webcrypto flag.

[wpessers]

I believe it's this test run and the reason I came to the original conclusion is logs like following: https://github.com/open-telemetry/opentelemetry-js-contrib/actions/runs/25566077066/job/75050744713?pr=2981#step:9:6390

ReferenceError: crypto is not defined

[wpessers]

@kuhe It's a bit misleading but I believe the documentation you're referring to is not necessarily the right one here, when I reported the issue smithy was using crypto.getRandomValues:

smithy-typescript/packages/core/src/submodules/serde/uuid/v4.ts

Line 29 in 7ec62a0

crypto.getRandomValues(rnds);

No importing of the crypto module, you're using the API here from globalthis.crypto. Documentation of which is found here: https://nodejs.org/docs/latest-v18.x/api/globals.html#crypto_1 and as you can see it still notes that same feature flag I mentionend earlier.

The docs page you linked to is the one for the getRandomValues that is exported from the actual node:crypto module. Which we'd be using if it was explicitly imported / required.

[wpessers]

Also the reason for it working for you with mise might have to do with the exact invocation mode used. Of course I can only guess how you checked this, but I'm guessing different invocation modes (like REPL, -p, -e) might expose globalthis.crypto even though the documentation says it's gated by that feature flag. A quick check:

docker run --rm node:18 node -e 'console.log(typeof globalThis.crypto)'

Indeed, this prints object. However, running in normal "script" mode:

docker run --rm node:18 sh -c 'echo "console.log(typeof globalThis.crypto)" > /tmp/s.js && node /tmp/s.js'

prints undefined

And in our case the tests use mocha as test runner, which of course just executes scripts and thus falls in that second bucket where globalthis.crypto is undefined.