Yichen Jiang
aaf58eb5bf
Second review round on the contained-group composition:
- Ownership scanned only `insert` rows, so an external bundle could set a
built-in row's id as a child through `{ id: own, config: [...] }` and the
Loader re-parented that row under the bundle while `originOf` still named
the built-in layer. The rows an id-targeted patch sets as a group's config
now count as the layer's own: an external bundle that sets an id another
layer owns is left out whole, a built-in layer that takes another layer's
id fails loud, and a layer restating its own child is not a repeat.
- `recompose` read the committed profile before awaiting the update, so a
watcher firing while a bundle was being enabled composed the tree before
the enable and applied it after; the plugin vanished while `layers` kept
listing it. Recompositions now queue, each reading what the previous one
committed, and a rejection stays its own caller's outcome.
- A patch that replaced a built-in target's config removed the wrapper the
bundle had put there, yet later inserts still targeted the detached
wrapper and vanished. The composition forgets the wrapper on such an
override and creates a new one under the same id.
- Generated wrapper ids bypassed the duplicate check, so a bundle declaring
a row spelled like a wrapper produced two nodes with one id. Declared and
generated ids now go through one registration.
- Failure records outlived their rows when a bundle update dropped a failed
row without unmounting the group, or when a pending row sat in a plain
nested group whose id the record named. A contained group now drops the
records of rows its configuration no longer names after each update, and
the audit records every row under the contained group that isolates it.
- `applyEntryPatches` assigned override values by reference, so applying a
patch list carried a later insert's rows back into the patch object; the
vendored include now clones object-valued overrides as it does inserts.
description, kind
| description | kind |
|---|---|
| The boot package group: how dsh app bins start — environment loading, profile and patch layers, clear startup failures, and app-owned command lines. | package-group |
boot/ — shared app-bin boot glue
English | 中文
Summary
The boot group provides what every dsh app bin needs to start: app-boot turns a cordis.yml plus your environment and patch layers into a running app with clear failure messages, and cmdline lets the app own its command-line flags and --help. With these packages you can run dsh or write a new application or test fixture that boots the same way. Both are libraries imported by apps/cli and test-only Loader fixtures, never plugins a composition loads. This page maps the group; each package README owns its per-package contract.
Table of Contents
Packages
| Package | Role | ctx key |
|---|---|---|
app-boot |
Boots a dsh app from a cordis.yml: loads .env, applies profile and patch layers, and reports startup failures clearly |
(library for the bins) |
cmdline |
Lets the app own its flags, --help, and exit code; passes everything after the launcher's flags through verbatim |
cmdlineArgs, appExit |
Related documentation
- dsh app — the
dshbin that consumes these helpers for its boot sequence. - Profile bundles — installable patch layers that
dsh --profilecompositions mount. - dsh-home-paths — the harness-home resolver both packages build on.
- dsh-cmdline — how an app owns its flag family instead of the launcher.
Dev Note
None.