SDKs and language support#

One's platform implementation can remain predominantly Rust without requiring application code in every language to execute through Rust. SDKs project exact One contracts into idiomatic target-language APIs; they are not independent copies of Planning, Build, Authority, Deployment, or History.

Capability illustration: The worker and workflow API spellings on this page remain illustrative. The current TypeScript implementation covers bounded unary contract values and clients only; higher capability sets remain typed unavailable.

Support has explicit depth#

“Supports Python” or “supports TypeScript” is incomplete without naming the capability:

A lower capability does not imply a higher one. Generating a TypeScript client does not make TypeScript a complete .one implementation-body language, and a wire-compatible Python server does not prove portable workflow replay.

Generated contracts, ordinary code#

A generated target-language package supplies exact types and symbolic operation references:

import { OneClient } from "@one/sdk";
import {
  FulfillmentClient,
  type FulfillOrderInput,
} from "@parcelhub/contracts";

const client = new FulfillmentClient(
  await OneClient.connect({ endpoint }),
);

const run = await client.fulfillOrder.start({
  orderId: "order-123",
} satisfies FulfillOrderInput);

const result = await run.result();

The validator, constructors, and pure helpers can run entirely in TypeScript. The client can communicate directly with an admitted remote endpoint over the selected protocol. A local Rust daemon or FFI call is not implied.

Server and activity SDKs add generated handler interfaces and a language runtime host:

import { service } from "@one/sdk";
import { Greeter, Greeting } from "claim";

export default service.implements(Greeter, {
  async sayHello(cx, request) {
    await cx.checkpoint();
    return Greeting.create({
      message: `Hello, ${request.name}!`,
    });
  },
});

Planning selects whether that implementation is embedded, a WebAssembly component, a separate process, or remote. The chosen boundary makes codecs, copies, lifecycle, isolation, failure, authority, and cost visible.

Full implementation support is more than an SDK#

To admit a Python, TypeScript, Go, or other body in a .one implementation item, the exact using profile must resolve:

• the source-language definition and release;
• parser, analyzer and formatter contracts and admitted tools;
• the contract projection and runtime-support revisions;
• package/module dependency and target constraints;
• compiler/build and worker/runtime realization; and
• artifact, conformance, binding and admission evidence.

Generic .one tooling can still frame and preserve an unavailable language body byte-for-byte. Language-aware checking and building return typed unavailable output rather than guessing from an installed SDK.

Provider-specific SDKs remain available#

Portable One SDKs are the ordinary path, but an implementation can deliberately use a provider SDK such as Temporal's. Its exact profile and dependency closure make that descent and portability loss visible. One can still own the semantic contract, artifact, provider selection, authority, deployment and evidence around the provider-specific code.

Task queues, worker registration, endpoints, credentials and grants are normally derived from the selected plan. A user-authored provider bootstrap is allowed as an explicit external/provider-specific component; One claims only the integration and evidence that actually enter its contracts.

Current implementation#

The repository currently provides the Rust facade and lower Rust atoms plus a receipted generated Rust contract projection used by ParcelHub's typed Get and Place clients. Native One is an implemented body language for the bounded SafeAsync unary slice, with exact analysis, bytecode and Component Build, and runtime evidence.

TypeScript now has a Contracts-owned values-client/v1 projection and the dependency-free @one/contracts support package. It generates strict ESM types, validators, canonical OCS binary codecs, structured exits, and bounded unary client functions when an exact physical boundary is supplied. It uses bigint for integers and identifiers rather than silently mapping U64-like values to JavaScript number. Peer-language worker hosts, portable workflow SDKs, package-resolution UX, and a TypeScript implementation-body profile are still unavailable.

Continue with implementation items, interoperability, and workflows and effects.

Canonical owners: Contracts, System IDL, Build, and Developer Interface.