You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/guide/migration-0.9.md
+67-1Lines changed: 67 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -4,7 +4,7 @@ outline: deep
4
4
5
5
# Migrating to 0.9
6
6
7
-
0.9 removes the compatibility shims that were deprecated across the 0.7 series. Each removed export has a drop-in replacement that has shipped alongside it since 0.7, so migrating is a matter of updating import paths and a handful of call sites. This page covers the changes between 0.8.x and 0.9.
7
+
0.9 removes the compatibility shims that were deprecated across the 0.7 series and trims the public API surface of `devframe` and `@devframes/hub` down to what integrations actually consume. Each change has a drop-in replacement, so migrating is a matter of updating import paths and a handful of call sites. This page covers the changes between 0.8.x and 0.9.
`createJsonRenderView` returns a view carrying a serializable `ref` (a shared-state key or an inline spec). Project it onto a hub dock with `toJsonRenderDockEntry` from `@devframes/json-render/hub`, which contributes the `'json-render'` dock type to the hub's open dock union. A dock entry now carries that serializable `view` ref rather than a live renderer handle — a client reads `entry.view.stateKey` (or `entry.view.spec`) to render it.
97
97
98
98
See [JSON-Render](./json-render) for the full integration reference.
99
+
100
+
## `defineDevframe` moves to the package root
101
+
102
+
`defineDevframe` — the primary authoring helper — now lives on the `devframe` entry point alongside `defineRpcFunction`. `devframe/types` is now strictly type-only. Import both values and types from `devframe`:
103
+
104
+
| 0.8.x | 0.9 |
105
+
|-------|-----|
106
+
|`import { defineDevframe } from 'devframe/types'`|`import { defineDevframe } from 'devframe'`|
107
+
|`import type { DevframeNodeContext } from 'devframe/types'`|`import type { DevframeNodeContext } from 'devframe'`|
`devframe/types` still resolves as the type-only subpath — useful for `declare module 'devframe/types'` augmentations — but `devframe` is the canonical import for both values and types.
116
+
117
+
## `devframe/utils/{promise,scope}` are removed
118
+
119
+
Two utility subpaths with no integration consumers are removed:
120
+
121
+
| Removed | Replacement |
122
+
|---------|-------------|
123
+
|`import { promiseWithResolver } from 'devframe/utils/promise'`|`Promise.withResolvers()` (native) |
124
+
|`import { isQualifiedName, qualifyName } from 'devframe/utils/scope'`| Inline the check (`name.includes(':')`) |
125
+
126
+
The other `devframe/utils/*` helpers — `colors`, `open`, `launch-editor`, `hash`, `nanoid`, `crypto-token`, `structured-clone`, `events`, `shared-state`, `streaming-channel`, `when`, `simple-schema`, `serve-static`, `agent-tool-name` — are unchanged.
127
+
128
+
## `devframe/node` is slimmed to the context surface
129
+
130
+
`devframe/node` keeps just the context-building API — `createHostContext` (+ `CreateHostContextOptions`), `createStorage` (+ `CreateStorageOptions`), and the `RpcFunctionsHost` type. Serve a devframe through the adapters (`createDevServer`, `createBuild`, `createCac`) or [`devframe/initiate`](../adapters/initiate); build a context to embed one with `createHostContext`.
131
+
132
+
The internal host implementations and low-level factories are no longer exported at all:
133
+
134
+
| Removed from `devframe/node`| Notes |
135
+
|---|---|
136
+
|`DevframeDiagnosticsHost`, `DevframeServicesHostImpl`, `DevframeViewHost` (classes) | Internal host implementations. The same-named **types** remain on `devframe/types`. |
137
+
|`createRpcSharedStateServerHost`, `createRpcStreamingServerHost`| Wired internally by `createContextRpcServer`. |
138
+
|`createScopedNodeContext`, `createNodeSettings`| Internal to context assembly. |
139
+
|`toDialableHost`, `formatHostForUrl`, `isObject`| Internal helpers (`isObject` is removed entirely — inline `typeof x === 'object' && x !== null`). |
140
+
141
+
## Cross-package internals move to `devframe/internal`
142
+
143
+
The low-level primitives shared between `devframe` and its first-party integrations (`@devframes/hub`, the inspect plugin, `@vitejs/devtools`, custom hosts) now live at the new `devframe/internal` entry point, which is explicitly **unstable** (it can change in any minor release). They were previously on `devframe/node`:
A host that stands up its own server composes from `devframe/internal` — `createH3DevframeHost` for the node `DevframeHost`, `startHttpAndWs` (or `createContextRpcServer` + `devframe/rpc/server` + `devframe/rpc/transports/*`) to bind a transport — plus `devframe/node`'s `createHostContext` and `devframe/node/hub-internals`. This is the path `@devframes/hub`'s `initHub` takes. A custom host advertises itself with `registerDevframeInstance`, and a devtool enumerates running instances with `listLiveDevframeInstances`. Application code should prefer the adapters and `devframe/initiate`.
156
+
157
+
## `@devframes/hub` category order lives only on `/constants`
158
+
159
+
`DEFAULT_CATEGORIES_ORDER` is now exported only from `@devframes/hub/constants` (its documented single source of truth). The redundant re-exports from `@devframes/hub`, `@devframes/hub/node`, and `@devframes/hub/client` are removed:
0 commit comments