Skip to main content

​
What changed

The user-facing types that the three SDKs share with the engine move out of the root SDK into a new package, @iii-dev/helpers (npm), iii-helpers (crate and PyPI, import iii_helpers). The package is organized into four submodules. This is a breaking change: the moved symbols are removed from the root SDK and are importable only from the helpers package.
SubmoduleNodePythonRust
http@iii-dev/helpers/httpiii_helpers.httpiii_helpers::http
queue@iii-dev/helpers/queueiii_helpers.queueiii_helpers::queue
stream@iii-dev/helpers/streamiii_helpers.streamiii_helpers::stream
worker-connection-manager@iii-dev/helpers/worker-connection-manageriii_helpers.worker_connection_manageriii_helpers::worker_connection_manager

​
Moved symbols

SubmoduleSymbols
httpHttpAuthConfig, HttpInvocationConfig, HttpMethod, the http handler helper, buffered HttpRequest and HttpResponse
queueEnqueueResult (also re-exported from the root SDK, see below)
streamthe stream trigger configs, events, IO inputs, auth and result types, and the update operations (UpdateOp, UpdateOpError, MergePath, UpdateSet, UpdateMerge, and the other Update* variants)
worker-connection-managerAuthInput, AuthResult, and the six On{Function,Trigger,TriggerType}Registration{Input,Result} types

​
What stays in the root SDK

Types that reference core-only types stay in the root SDK in all three languages, because moving them would create a dependency cycle from the helpers package back into the core SDK: IStream, the streaming StreamRequest and StreamResponse, MiddlewareFunctionInput, and TriggerActionEnqueue. The root SDK depends on iii-helpers and imports the moved types from the submodules internally where its own code needs them. EnqueueResult is the exception in the queue submodule: its canonical home is iii_helpers::queue, but it is also re-exported from the root SDK as the return companion to TriggerAction.Enqueue, so it remains importable from iii-sdk / iii / iii_sdk without a migration.

​
Migration

Import the moved types from the helpers package. Node: 
// Before
import { HttpAuthConfig } from 'iii-sdk'
// After
import { HttpAuthConfig } from '@iii-dev/helpers/http'
// EnqueueResult needs no migration; it stays importable from 'iii-sdk'
Python: 
# Before
from iii import HttpInvocationConfig, AuthInput
# After
from iii_helpers.http import HttpInvocationConfig
from iii_helpers.worker_connection_manager import AuthInput
Rust: 
// Before
use iii_sdk::{HttpAuthConfig, StreamTriggerConfig};
// After
use iii_helpers::http::HttpAuthConfig;
use iii_helpers::stream::StreamTriggerConfig;

​
Why

These types are part of the shared contract between the SDKs and the engine. Housing them in one separately versioned package gives a single source of truth, lets consumers depend on only the surface they need, and keeps the root SDK focused on the worker and runtime API. It follows the @iii-dev/observability precedent. The helpers package has no dependency on the root SDK, so the dependency direction stays one way.