Skip to content

feat(typescript): add a client target with @nexus.poll - #101

Draft
moetemp wants to merge 1 commit into
moe/up/upstream-combinedfrom
moe/up/typescript-client-target
Draft

moetemp wants to merge 1 commit into
moe/up/upstream-combinedfrom
moe/up/typescript-client-target

Conversation

@moetemp

@moetemp moetemp commented Oct 31, 2026

Copy link
Copy Markdown
Owner

What changed?

This PR adds the client target to the TypeScript generator, with the @nexus.poll iterator of temporalio#325.

  • With --targets workflow,client, the output gets a client/ package. It has a client extension mixin per service, its own resource classes and get<Resource>.
  • A client class implements createNexusClient, which can return client.nexus.createServiceClient(options). A client resource takes that service-bound client first, and each call uses a new random operation ID.
  • @nexus.poll with a typescript helper gives iter<Name>.
  • A proto-bound 64-bit value of a client resource is Long, as in fix(typescript): infer Long from protobuf resource bindings temporalio/nexgen#345.
  • Output without the Workflow target writes each resource with its fields only, since its resources.ts imported operation files that it didn't write.

Why?

The Python client target of temporalio#344 has no TypeScript half.

How did you test it?

Link to a test plan if any -

  • Unit Tests
  • Staging
  • End to End Tests

stream-client.test.ts checks a create, a rebuilt handle and the read loop with a fake client. tsc checks it and the stream output.

The stream sample's TypeScript output gets the client API and the read iterator that Python has.
A client resource takes a service-bound Nexus client, as in Python.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant