RLC: bytes request body emits NodeJS.ReadableStream union arm, breaking browser build (TS2503)

[siddharthUCD]

Package
@azure-tools/typespec-ts (RLC emitter)

Summary
For an operation whose request body is bytes, the RLC emitter generates a parameter type that includes NodeJS.ReadableStream. The Azure SDK for JS browser tsconfig sets "types": [] and intentionally excludes @types/node, so the browser compile fails with TS2503: Cannot find namespace 'NodeJS'. Node CJS/ESM targets compile fine; only the browser target fails.

Affected spec / PR

• Spec: specification/confidentialledger/Microsoft.CodeTransparency in Azure/azure-rest-api-specs
• PR: Stable API version for MST 2026-03-26 37284272 azure-rest-api-specs#41834
• Generated SDK package: @azure-rest/codetransparency (sdk/confidentialledger/codetransparency-rest)

Minimal TypeSpec that triggers it
`model SignedStatement {
@Header("Content-Type")
contentType: "application/cose";

@bodyRoot
body: bytes;
}

@post
@route("/entries")
op createEntry is Foundations.Operation<
SignedStatement & AcceptCoseOrCborHeader,
CreateEntryCreated | CreateEntryPending,
ServiceTraits,
AnyCborError

;`

Generated output (excerpt)
sdk/confidentialledger/codetransparency-rest/src/parameters.ts, line 53:
// Roughly: body: string | Uint8Array | ReadableStream<Uint8Array> | NodeJS.ReadableStream;

The NodeJS.ReadableStream arm is the offender.

Build error
sdk/confidentialledger/codetransparency-rest/src/parameters.ts(53,60): error TS2503: Cannot find namespace 'NodeJS'. [warp] Build failed for targets: browser ERR_PNPM_RECURSIVE_RUN_FIRST_FAIL @azure-rest/codetransparency@1.0.0-beta.1 build

Repro steps

1. Use any TypeSpec data-plane operation whose request body is bytes.
2. Run the spec-gen-sdk pipeline (or locally: pnpm run --filter @azure-rest/<pkg>... build after generation).
3. Browser target compilation fails with TS2503 on the generated parameters.ts.

Expected behavior
The emitter should produce a type union for binary request bodies that compiles in both Node and browser targets. Options:

• Replace NodeJS.ReadableStream with a structural type like AsyncIterable<Uint8Array>.
• Or split the parameter type across src/node/ and src/browser/ files selected via the package.json exports node/browser conditions (consistent with how the rest of azure-sdk-for-js isolates Node-only APIs).

Actual behavior
A single parameters.ts with NodeJS.ReadableStream is emitted and consumed by all build targets, breaking the browser build wherever @types/node is excluded (which is repo policy).

Environment

• Emitter: @azure-tools/typespec-ts (version used by spec-gen-sdk at run time — please confirm from your pipeline; see azure-sdk-for-js lockfile)
• TypeScript: 6.0.3 (per the API Extractor warning in the build log)
• azure-sdk-for-js: HEAD at time of pipeline run
• Repo policy: Browser tsconfigs in azure-sdk-for-js set "types": [] to exclude @types/node

Workaround used in the spec repo
Added a client.tsp next to the spec narrowing the JS-side type:
@@alternateType(Microsoft.CodeTransparency.SignedStatement.body, string, "javascript");

This unblocks the pipeline but degrades JS ergonomics (callers must pass a base64-encoded string instead of a binary). We would like to remove the workaround once this is fixed upstream.

Impact
Blocks JS SDK generation for any data-plane service with binary request bodies. Other emitters (Python/C#/Java/autorest) are unaffected.

[jeremymeng]

maybe we should use import { NodeReadableStream } from "#platform/static-helpers/platform-types";?

[siddharth9606]

Agreed on the direction. I was thinking something in the lines of a structural type like AsyncIterable<Uint8Array> in the union. So that we won't need any changes to pAckage.json and Node Readable streams already satisfy `AsyncIterable.
This is based on my limited understanding, you would know better

[siddharthUCD]

Update:
The workaround did not work out the error is still identical

[jeremymeng]

We will need codegen fix. I was thinking in the line of Azure/azure-sdk-for-js@cb34c78

[siddharthUCD]

That's great, thank you for the prompt help👍
One question may I know when the fix will land in the emitter templates? Just concerned the next auto-regen might rollback the changes