chore(release): version packages

[github-actions]

This PR was opened by the Changesets release GitHub action. When you're ready to do a release, you can merge this and the packages will be published to npm automatically. If you're not ready to do a release yet, that's fine, whenever you add more changesets to main, this PR will be updated.

Releases

@dunky.dev/dom-dialog@0.1.0

Minor Changes

• #44 e3a5e96 Thanks @ivanbanov! - New package: @dunky.dev/dom-dialog, the framework-free DOM half of the
  Dialog. The React and Solid bindings had grown two copies of the same
  document-level code — the Escape listener, the ordered focus/stack sequence
  around the open edge, the exit window, the session-history guard, the
  outside-press gating — differing only in which lifecycle scheduled them. That
  duplication is the drift risk the architecture exists to remove, and it would
  have been copied a third time for Vue.

  Both bindings now contribute only their host's lifecycle:

  // before — the same twenty lines in every DOM substrate
  const previous = document.activeElement
  const unregister = registerLayer({
    id,
    depth,
    element: content,
    modal,
    backdrop,
  })
  const target = initialFocus ?? getInitialFocus(content)
  target.focus({ preventScroll: true })
  // ...
  
  // after
  return openDialogLayer(content, { id, depth, modal, backdrop, initialFocus })

  The ordering that made those sequences correct — the stack joins before focus
  moves in, and releases the layers beneath before focus moves back out — is now
  stated and tested in one place rather than re-derived per substrate.

  No consumer-visible behavior changes in either binding; this is an internal
  extraction. @dunky.dev/dom-dialog is published because the bindings depend on
  it at runtime, and a substrate outside this repo can build on it directly.

  This also establishes packages/dom/components/ as a layer: a DOM package
  scoped to one primitive, which may import that primitive's core package and any
  DOM util, but never a framework. pnpm scaffold <name> stamps one for every new
  primitive.

Patch Changes

• Updated dependencies [e3a5e96]:
  • @dunky.dev/dialog@0.3.1

@dunky.dev/react-dialog@0.3.0

Minor Changes

• #40 148ee66 Thanks @ivanbanov! - Dialog.Content now renders a <div> carrying the dialog (or alertdialog) role instead of the native <dialog> element. Consumers styling dialog { ... } should target the part directly (or its role), and a forwarded ref is now an HTMLDivElement; ...props accept ComponentProps<'div'>.

  The dialog window is the initial focus target — focusable in script, out of the tab order — which needs tabindex="-1", and HTML states that the tabindex attribute must not be specified on dialog elements. The native element would only pay off through showModal(), and this contract deliberately keeps modality, dismissal, and focus in the core machine rather than splitting authority with the browser's built-in behavior — so the element brought nothing but a conformance violation. Nothing about the exposed semantics changes: the same role, aria-modal, name, description, and focus behavior as before. UA <dialog> resets (position: static, border: none) are no longer needed in consumer styles.

Patch Changes

• #44 e3a5e96 Thanks @ivanbanov! - New package: @dunky.dev/dom-dialog, the framework-free DOM half of the
  Dialog. The React and Solid bindings had grown two copies of the same
  document-level code — the Escape listener, the ordered focus/stack sequence
  around the open edge, the exit window, the session-history guard, the
  outside-press gating — differing only in which lifecycle scheduled them. That
  duplication is the drift risk the architecture exists to remove, and it would
  have been copied a third time for Vue.

  Both bindings now contribute only their host's lifecycle:

  // before — the same twenty lines in every DOM substrate
  const previous = document.activeElement
  const unregister = registerLayer({
    id,
    depth,
    element: content,
    modal,
    backdrop,
  })
  const target = initialFocus ?? getInitialFocus(content)
  target.focus({ preventScroll: true })
  // ...
  
  // after
  return openDialogLayer(content, { id, depth, modal, backdrop, initialFocus })

  The ordering that made those sequences correct — the stack joins before focus
  moves in, and releases the layers beneath before focus moves back out — is now
  stated and tested in one place rather than re-derived per substrate.

  No consumer-visible behavior changes in either binding; this is an internal
  extraction. @dunky.dev/dom-dialog is published because the bindings depend on
  it at runtime, and a substrate outside this repo can build on it directly.

  This also establishes packages/dom/components/ as a layer: a DOM package
  scoped to one primitive, which may import that primitive's core package and any
  DOM util, but never a framework. pnpm scaffold <name> stamps one for every new
  primitive.

• #44 e3a5e96 Thanks @ivanbanov! - Update the state-machine packages to the 2026-08-22 release: runtime 0.3.3,
  bindings 0.4.1, utils 0.4.0, and the React (0.3.4), Solid (0.3.0), and
  native (0.4.0) adapters.

  Every range moves together on purpose. The published adapters pin the runtime
  exactly (@dunky.dev/state-machine: 0.3.3), so a package left on an older
  caret would have pulled a second physical copy of the runtime into a consumer's
  install — the dependency diamond ARCHITECTURE.md warns about, where anything
  identity-sensitive (a singleton, a WeakMap, module-level state) silently stops
  agreeing across the two copies. @dunky.dev/controllable was the oldest
  offender, still on ^0.1.0; the tree now resolves to a single runtime.

• Updated dependencies [e3a5e96, e3a5e96]:

  • @dunky.dev/dom-dialog@0.1.0
  • @dunky.dev/dialog@0.3.1

@dunky.dev/solid-dialog@0.1.0

Minor Changes

• #44 4480950 Thanks @ivanbanov! - New substrate: the Solid binding for @dunky.dev/dialog, targeting Solid 2.0
  (peers: solid-js and @solidjs/web at ^2.0.0-rc.1; 1.x is unsupported —
  the binding stands on 2.0's primitives). The same compound anatomy and
  behavior contract as the React binding — one core machine, a new host —
  delivered in Solid's native shape: the connected api is a fine-grained store,
  so a machine transition updates exactly the bindings that changed, and the
  core options are plain reactive props (per the controlled contract a
  dismissal on a controlled dialog reports nothing — decide it at its source in
  the dismissal callbacks, which carry preventDefault() for the veto).

  import { Dialog } from '@dunky.dev/solid-dialog'
  ;<Dialog open={open()} onOpenChange={setOpen} onEscapeKeyDown={() => setOpen(false)}>
    <Dialog.Trigger>Open</Dialog.Trigger>
    <Dialog.Portal>
      <Dialog.Backdrop />
      <Dialog.Viewport>
        <Dialog.Content>
          <Dialog.Title>Title</Dialog.Title>
          <Dialog.Description>Description</Dialog.Description>
          <Dialog.Close>Close</Dialog.Close>
        </Dialog.Content>
      </Dialog.Viewport>
    </Dialog.Portal>
  </Dialog>

  Content's initialFocus accepts an element or an accessor resolved at open
  time — the Solid idiom for a ref variable that fills during render, so
  initialFocus={() => cancelButton} works. Everything else follows the core
  spec: layer stack with assistive-tech containment, focus trap with Close as
  the cycle's last stop, scroll lock (scoped to the Portal container when
  given), exit animations through data-state="closing", and closeOnBack.

Patch Changes

• #44 e3a5e96 Thanks @ivanbanov! - New package: @dunky.dev/dom-dialog, the framework-free DOM half of the
  Dialog. The React and Solid bindings had grown two copies of the same
  document-level code — the Escape listener, the ordered focus/stack sequence
  around the open edge, the exit window, the session-history guard, the
  outside-press gating — differing only in which lifecycle scheduled them. That
  duplication is the drift risk the architecture exists to remove, and it would
  have been copied a third time for Vue.

  Both bindings now contribute only their host's lifecycle:

  // before — the same twenty lines in every DOM substrate
  const previous = document.activeElement
  const unregister = registerLayer({
    id,
    depth,
    element: content,
    modal,
    backdrop,
  })
  const target = initialFocus ?? getInitialFocus(content)
  target.focus({ preventScroll: true })
  // ...
  
  // after
  return openDialogLayer(content, { id, depth, modal, backdrop, initialFocus })

  The ordering that made those sequences correct — the stack joins before focus
  moves in, and releases the layers beneath before focus moves back out — is now
  stated and tested in one place rather than re-derived per substrate.

  No consumer-visible behavior changes in either binding; this is an internal
  extraction. @dunky.dev/dom-dialog is published because the bindings depend on
  it at runtime, and a substrate outside this repo can build on it directly.

  This also establishes packages/dom/components/ as a layer: a DOM package
  scoped to one primitive, which may import that primitive's core package and any
  DOM util, but never a framework. pnpm scaffold <name> stamps one for every new
  primitive.

• Updated dependencies [e3a5e96, 4480950, e3a5e96]:

  • @dunky.dev/dom-dialog@0.1.0
  • @dunky.dev/solid-use-focus-trap@0.1.0
  • @dunky.dev/solid-use-scroll-lock@0.1.0
  • @dunky.dev/dialog@0.3.1

@dunky.dev/solid-use-focus-trap@0.1.0

Minor Changes

• #44 4480950 Thanks @ivanbanov! - New substrate: the Solid lifecycle wrappers over the framework-free DOM utils,
  mirroring the React hooks one-for-one and targeting Solid 2.0 (peer
  solid-js@^2.0.0-rc.1). useFocusTrap(target, options?) takes an accessor
  for the container (a plain ref variable fills during render, so the trap arms
  on mount and re-arms when a reactive accessor yields a new element);
  useScrollLock(locked?, target?) accepts a MaybeAccessor for both
  parameters so the lock tracks reactive state. The behavior itself lives in
  @dunky.dev/dom-focus-trap and @dunky.dev/dom-scroll-lock — these
  primitives own only the lifecycle.

@dunky.dev/solid-use-scroll-lock@0.1.0

Minor Changes

• #44 4480950 Thanks @ivanbanov! - New substrate: the Solid lifecycle wrappers over the framework-free DOM utils,
  mirroring the React hooks one-for-one and targeting Solid 2.0 (peer
  solid-js@^2.0.0-rc.1). useFocusTrap(target, options?) takes an accessor
  for the container (a plain ref variable fills during render, so the trap arms
  on mount and re-arms when a reactive accessor yields a new element);
  useScrollLock(locked?, target?) accepts a MaybeAccessor for both
  parameters so the lock tracks reactive state. The behavior itself lives in
  @dunky.dev/dom-focus-trap and @dunky.dev/dom-scroll-lock — these
  primitives own only the lifecycle.

@dunky.dev/dialog@0.3.1

Patch Changes

• #44 e3a5e96 Thanks @ivanbanov! - Update the state-machine packages to the 2026-08-22 release: runtime 0.3.3,
  bindings 0.4.1, utils 0.4.0, and the React (0.3.4), Solid (0.3.0), and
  native (0.4.0) adapters.

  Every range moves together on purpose. The published adapters pin the runtime
  exactly (@dunky.dev/state-machine: 0.3.3), so a package left on an older
  caret would have pulled a second physical copy of the runtime into a consumer's
  install — the dependency diamond ARCHITECTURE.md warns about, where anything
  identity-sensitive (a singleton, a WeakMap, module-level state) silently stops
  agreeing across the two copies. @dunky.dev/controllable was the oldest
  offender, still on ^0.1.0; the tree now resolves to a single runtime.

• Updated dependencies [e3a5e96]:

  • @dunky.dev/controllable@0.1.2

@dunky.dev/controllable@0.1.2

Patch Changes

• #44 e3a5e96 Thanks @ivanbanov! - Update the state-machine packages to the 2026-08-22 release: runtime 0.3.3,
  bindings 0.4.1, utils 0.4.0, and the React (0.3.4), Solid (0.3.0), and
  native (0.4.0) adapters.

  Every range moves together on purpose. The published adapters pin the runtime
  exactly (@dunky.dev/state-machine: 0.3.3), so a package left on an older
  caret would have pulled a second physical copy of the runtime into a consumer's
  install — the dependency diamond ARCHITECTURE.md warns about, where anything
  identity-sensitive (a singleton, a WeakMap, module-level state) silently stops
  agreeing across the two copies. @dunky.dev/controllable was the oldest
  offender, still on ^0.1.0; the tree now resolves to a single runtime.

@dunky.dev/native-dialog@0.1.1

Patch Changes

• #44 e3a5e96 Thanks @ivanbanov! - Update the state-machine packages to the 2026-08-22 release: runtime 0.3.3,
  bindings 0.4.1, utils 0.4.0, and the React (0.3.4), Solid (0.3.0), and
  native (0.4.0) adapters.

  Every range moves together on purpose. The published adapters pin the runtime
  exactly (@dunky.dev/state-machine: 0.3.3), so a package left on an older
  caret would have pulled a second physical copy of the runtime into a consumer's
  install — the dependency diamond ARCHITECTURE.md warns about, where anything
  identity-sensitive (a singleton, a WeakMap, module-level state) silently stops
  agreeing across the two copies. @dunky.dev/controllable was the oldest
  offender, still on ^0.1.0; the tree now resolves to a single runtime.

• Updated dependencies [e3a5e96]:

  • @dunky.dev/dialog@0.3.1