typescript SDK, node and ts upgrades

[vandervillain]

This branch builds out the TypeScript SDK to feature parity with the Java, Python, and Go SDKs. The remaining differences are intentional and documented in IWF_SDK_FEATURES.md.

What's here

• Core: workflow/state definitions, the waitUntil/execute lifecycle, commands and command results, and all state-decision types (including conditional close).
• Persistence: data attributes, all search-attribute types, state locals, event recording, and prefix-based dynamic data attributes/channels.
• Communication: signal and internal channels, publishing, and channel-size queries.
• RPC: define, invoke, and the worker-side handler.
• The full client API (start, stop, describe, reset, signals, search, attributes, timers, RPC, results) with start options like delay, initial attributes, idempotent start, and waiting on specific states to finish.

Parity audit
I audited the whole surface against the Java SDK and closed every gap it found — execute-failure recovery state, per-API persistence loading policies, useMemoForDataAttributes, no-wait "try-get" results, workflowAlreadyStartedOptions / skipUpdateReapply, sending registered search-attribute key-types on RPC, and the runtime validation Java does (single starting state, attribute-type checks, empty-decision rejection, duplicate recordEvent keys, publish-and-wait on one channel, duplicate registration, etc.). Also fixed getSearchAttributeInt precision and the datetime format handling.

Housekeeping

• Bumped iwf-idl to 1.0.0-121 and regenerated the client; fixed several skeleton bugs (wrong server URL, a misspelled context field, a mapper that dropped commands, a config option that was never stored, and the worker RPC callback path).
• Moved the build to nodenext + isolatedModules (still CommonJS output, no downstream change).
• Dependency cleanup: dropped immutable (cleared a prototype-pollution advisory), bumped axios and jest; npm audit is clean.

A few things are deliberately idiomatic for TS: a pluggable ObjectEncoder instead of Class-based typing, a flatter error model with boolean getters, and a single string-named RPC handler instead of Java's functional-interface variants.

[longquanzheng]

would be nice to start with adding the CI workflow in github action, like other SDKs. otherwise looks great.

[vandervillain]

would be nice to start with adding the CI workflow in github action, like other SDKs. otherwise looks great.

@longquanzheng are you referring running integration tests on PR merge? (like https://github.com/indeedeng/iwf-java-sdk/blob/main/.github/workflows/ci-integ-test.yml). I can get those in if so.

We're also building out an internal repo with typescript samples (similar to all the java samples) and verifying 100% parity before merging this PR. We'll probably add a more generic version of those samples for the public space as well.

[longquanzheng]

would be nice to start with adding the CI workflow in github action, like other SDKs. otherwise looks great.

@longquanzheng are you referring running integration tests on PR merge? (like https://github.com/indeedeng/iwf-java-sdk/blob/main/.github/workflows/ci-integ-test.yml). I can get those in if so.

We're also building out an internal repo with typescript samples (similar to all the java samples) and verifying 100% parity before merging this PR. We'll probably add a more generic version of those samples for the public space as well.

yes exactly.