Yichen Jiang
dc9256536b
Master now carries the final #4182 plugin manager and the live client module graph of #4189, so the web management layer is re-ported onto them: - The manager keeps master's `ManagementError` codes, `ChangeResult` stages, `configure()` under `hmr.runExclusive`, `reload()` warnings and `writePluginEnabled` name matching, and adds back `inspect`, request-id installs with `plugin-manager/install-log` and `plugin-manager/install-state`, `cancelInstall`, `listBundles` titles, rows and overrides, `packageResult.kind`, `pnpmCommand` and `inspectTimeoutMs`, and `plugin-manager/changed` after each change and each `profile/reconciled`. A failed or cancelled installation restores the snapshotted manifest and lockfile instead of master's one-shot `pnpm remove` cleanup, so `cleanup` and `remainingDependencies` leave the result. - App boot keeps master's reconciliation diagnostics and emits `profile/reconciled`; `watchUserPatches` goes with the launcher's watcher now that HMR owns profile reloads. - The settings Plugin list tab stays read-only with #4189's page-local sync failures and retry; master's bundle form and row checkboxes are dropped again. The sidebar page words the Host's codes through its dictionary, and a client bundle change follows the live module graph without a page reload. - The web e2e scaffold no longer chooses a reload policy: the base bundle's `hmr` row turns on with the profile context and application readiness, and `profile.hmr: false` disables it through an overlay for the startup-only scenario.
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 launches profile applications and manages their installed composition. app-boot resolves configuration and starts the Loader, cmdline supplies application arguments, and plugin-manager exposes current-profile operations shared with the CLI. Each package README owns its details.
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 |
hmr |
Coordinates module and configuration reloads with package mutations | hmr |
plugin-manager |
Manages current-profile plugins and bundle packages through shared CLI operations | pluginManager |
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.
-
Profile management — service methods and result records.
Dev Note
None.