dshmarket 1.73.18: Nine Changes After a Skipped Evening, Three First-Time Contributors (Nov 11, 2026)

The nightly rhythm skipped an evening and came back with nine changes where the previous release had four: per the npm registry (fetched 2026-11-11), no dshmarket version carries a 2026-11-10 publish time, and 1.73.18 went up at 16:49:38 UTC on November 11, taking over the dist-tag latest — dshmarket 1.73.17: Three Fixes and a Market Speedup, All From First-Time Contributors (Nov 9, 2026) covered the last release before the gap. The GitHub release page stamps 16:42:32 UTC, authored by the repo’s github-actions bot, and links the compare range v1.73.17…v1.73.18.

Nine changes, seven authors, three first-timers

Per the release notes, the What’s Changed list holds nine items — eight fixes and one feature — and the New Contributors section names three authors making their first contribution: @ai-zen-future (#1169), @CyberYui (#1172) and @justinzyc271828-sys (#1173). The nine come from seven authors: @gongfpp and @Eapp1e land two each — per 1.73.16’s release notes, @Eapp1e was that evening’s one new name — and none of the four first-timers named in 1.73.17’s notes appears in this list.

The PR records’ merge stamps place five of the nine before release day. #1159 merged on 11-09 at 17:49 UTC, about forty minutes after 1.73.17 went up on npm; #1165 and #1166 merged together on 11-10 at 13:24 UTC, and #1168 and #1169 together at 16:48 UTC the same day. The other four merged at 16:41 UTC on 11-11, within a minute of the release page’s stamp.

PR #1177 (fix(toggle)) — enabling a carrier bundle no longer clears its disabled: !!js guards. Per issue #1175 (filed by Fomalhaut-hub at 10:04 UTC on 11-11, on dshmarket 1.73.17 with @deepseek-harness-tui/dsh-tui 0.19.0), switching DSH TUI on in the market’s plugin page wrote four -> on: fiber=true lines and then the whole dsh web process exited with StorageError: storage form 'domain' is already mounted; after a restart the plugin read as off again, so the open, exit, still-off loop could be repeated at will. Per the PR body, a carrier bundle’s patch prepares disabled: !!js … guards for rows the host may already mount — on the web profile storage-domain is mounted by dsh-base, the guard evaluates true, and boot is normal — but the live enable path did not honor them: setEntryDisabled(name, false) called update({ disabled: null }) on every matched entry, clearing the evaluated true, and dsh-tui-storage-domain mounted the domain form a second time in the same process; dsh fails loud on a duplicate mount, and the process exits. The body notes the persistent layer already had the rule — switchPluginLayers() skips such rows through bundleExpressionRowIds() (#1043) — and that the live layer ran ahead of it. The fix moves that rule one layer forward in two places: the live toggle skips rows a package decides by expression when enabling, and only when enabling, since a user’s intent to turn a guarded row off should always hold; and a carrier bundle’s enable, like its disable, is left to the next composition — the toggle route already reported restart: true for carriers. Per the body, two new flows cases are red without the fix, npm test reads 3329 passed with 4 skipped, and the issue’s third suggestion — that the carrier fallback in matchingEntries() should not count host-provided packages as a third-party bundle’s rows — is left in the issue for the maintainer to decide. Issue to merged fix took under seven hours: the PR opened at 14:37 UTC and merged at 16:41 UTC.
PR #1165 (fix(install)) — the removed-declaration notice clears by the installed package name. Per issue #1164 (filed by Start-Gao on DSH Desktop 0.2.2-rc.1), the Installed page kept showing an orange banner saying dsh-better-sidebar had been removed after a cancelled update, although the plugin had been reinstalled through the market on 2026-11-08 and read live; the banner survived page refreshes, desktop restarts and the market’s upgrade to 1.73.17, and the one thing that removed it was the manual dismiss — the issue notes that the designed path, clearing after a successful reinstall, writes an update-reinstalled log line the exported log did not contain. Per the PR body, brokenPlugins is keyed by the profile dependency name, while the install route cleared it with entry.name — the catalog’s display name, in the GitHub repo’s casing — so for every entry whose two names differ the clear hit a key that was never there and clearBrokenPlugin() returned before writing anything; the issue’s own case is a catalog entry named DSH-better-sidebar against the npm name dsh-better-sidebar. The fix clears by what the run actually put into the profile — the addedPackages set — plus the entry’s validated npm name; both are exact keys, so entries with no record stay a no-op and no other plugin’s notice can be cleared. Per the body, the regression test walks the reporter’s sequence on the real route and orchestration layers and is red with the one-line clear reverted; the flows and routes specs read 525 passed. On the issue, fkysly — who per the PR records merged all nine of this release’s PRs — confirmed the root cause on 11-10 and wrote that the fix would ship with the next version.
PR #1172 (fix(discovery)) — a host core package written as an ordinary dependency no longer passes as compatible, as the PR’s Chinese-language title puts it. Per issue #1171, which the PR’s author CyberYui filed about two minutes before opening the PR, deriveHostCompatibility() read only engines.dsh and peerDependencies, so a plugin declaring a host core package as an ordinary dependency was reported compatible or undeclared even when the running host could not satisfy the declared range — and pnpm installs that copy and hoists it over the host’s own. The incident on record: dsh-qqbot@1.0.2 declares @deepseek-ai/dsh-settings and @deepseek-ai/dsh-credentials at ^0.1.0-rc.5; on a profile using nodeLinker: hoisted, pnpm hoisted the resolved 0.1.0-rc.x over the runtime’s 0.2.2-rc.1, the loader disabled the settings row, the desktop welcome page’s settings/describe call got settings service is absent, and Desktop died on every launch until the profile was repaired by hand — while the market’s own pre-install compatibility check reported nothing. The issue ties this to a check issue #98 had asked for and quotes a src/check.ts comment still deferring it to a manifest PR that, per the issue, was never opened. Per the PR body, manifestFacts now reads manifest.dependencies, keeping the @deepseek-ai/ names, and two design decisions are pinned by tests: no peer leniency — ^0.0.1 is forgiven as a peer but must be refused as a dependency, because a dependency is an install instruction rather than a statement of intent — and no dsh- prefix restriction, because any host-provided package written as a dependency gets installed and hoisted. A missing dependencies field stays valid, so the durable cache survives the upgrade. Per the body: the discovery-compatibility spec reads 38 of 38, and npm test 3326 passed with 2 failures, both symlink-permission cases that fail on main too.
PR #1173 (fix(compat)) — the pnpm store reconnect advice follows the real precedence, again per a Chinese-language title. Per the PR body, the ERR_PNPM_UNEXPECTED_STORE branch gave everyone one line — write the store recorded in node_modules/.modules.yaml into the profile’s pnpm-workspace.yaml — while on pnpm 11.28.5 the author measured a longer chain deciding the store: --store-dir, then PNPM_CONFIG_STORE_DIR, then pnpm-workspace.yaml storeDir, then the global npmrc store-dir, then the default location. The body lists four situations where the old line fails with no hint: the profile already holds the recorded path (the #1100 scenario), the kebab spelling store-dir that pnpm ignores with only a WARN on stderr, an environment variable that outranks the file, and a recorded store that has been moved away. The third is the author’s own machine: PNPM_CONFIG_STORE_DIR pointed at a new disk, so following the advice twice still produced the same error the third time. The new message answers by the layer actually in effect and adds a check that proves the result — pnpm store path must print exactly the recorded path; when the path cannot be read it keeps the key name and the check rather than inventing a path. Per the body it adds no auto-repair — which store to use is the user’s own call, and the existing #244 test pins recoverable === false — and five new tests are red before the change; npm test reads 3319 passed with 8 failures the body attributes to missing symlink and junction permission on that Windows machine, failing on unmodified nightly1014 too.
PR #1168 (fix(settings)) and PR #1166 (fix(verify)) — two of the three silent failures issue #1144 reported on dsh 0.2.x, both by @Eapp1e. Per #1168’s body, from dsh 0.1.7 the settings service keeps only describe and update, with no register, and the host derives the form from the plugin’s own Config schema; what this repo exported was export type Config — a pure type with no schema at runtime — so the entry was skipped whole and the plugin settings page held no editable field for it. The fix adds a runtime export const Config built with schemastery, the package src/settings.ts already uses, so no dependency is added; allowRestart and maxSnapshots carry the volatile marker, every field and the root are .loose() so values already written in cordis.yml still boot, and hosts that have register keep their path untouched. The body flags one read that had to change with it: a field carrying the volatile marker resolves to a live reference rather than the value itself on the newer hosts, so apply() takes the value first in the three places it reads the two fields; left as it was, the register path handed that object to MarketSettings, validation threw, namespace registration failed and /dsh-market/status stayed at pending — which the body names as the direct cause of the all-red web-e2e runs across the 0.1.0, 0.1.2, 0.2.0 and 0.2.1 generations in CI. Per #1166’s body, @deepseek-ai/dsh-hooks-claude-code is installed as a dependency of the profile and works in every session that runs a preset using it, yet the card said installed, not in effect: verifyActivation asked only the bundle layer and the loader, neither of which can see a preset, whose plugins rows are mounted per session and never enter the host loader. The fix reads the profile’s own cordis.patch.yml, collects the agent-preset row’s presets[].plugins[].name, and answers with the presets that name the package; loader evidence still wins outright, so a package the host actually loaded stays live. The same body leaves #1144’s second item — the unknown desktop host version — to a separate PR.
PR #1159 (fix(updates)) — find-compatible reports the release-age wait only where the update enforces it. Per the PR body, since #1133 /dsh-market/find-compatible always attached a maturity answer; on a CLI host the update path retries once with --config.minimum-release-age=0, so a young release still installs — yet the dialog read held: true, said the version was still inside the release-age wait and disabled its update button, while the market’s own update list offered the same version. The fix returns maturity: null for an update on a non-desktop host, which the client already treats as offering the version; the desktop host and fresh installs keep the maturity answer as #1133 wrote it. Per the body, the new flows case fails on nightly1014 and passes with the fix, and npm test reads 3252 passed.
PR #1163 (fix) — versioned GitHub release archive names are recognized. Per the PR body, WhaleMaid 1.3.1 was also distributed as dsh-whalemaid-full-1.3.1.tgz while the current catalog advertises dsh-whalemaid-full.tgz, and the exact filename check introduced in #1119 left those older same-repository installs without an update button. The fix recognizes a filename with a stable numeric version suffix when that suffix equals the installed URL’s release tag and removing it yields the catalog asset name; the repository match, the catalog-approved update target, released-manifest validation and the downgrade checks stay, and unrelated assets, mismatched tags and pinned catalog entries still do not qualify. Per the body, all 572 affected tests passed. Per the PR record, this is the one change of the nine that targets main rather than nightly1014.
PR #1169 (feat(client)) — collapse all and expand all for plugin groups, the release’s one feature. Per the PR body, with many groups a user had to click each one to collapse or expand the list; the PR adds the two controls above the group list, reusing the existing collapse state and covering empty groups without touching ungrouped plugins or enabled state. The scope as the body records it: the buttons hide when there are no groups, each disables once everything is already collapsed or expanded, and during a search the matching groups and members keep showing with the batch controls disabled until the search clears. Copy ships in Chinese, English and Japanese, and no default-collapsed setting or persisted preference is added — issue #1129, which the body marks as closed by the PR, had asked for a default-state preference as well as the global buttons. Per the body, npm test reads 3322 passed with 3 skipped, and no native desktop run was done.

The notes list nothing beyond the nine.

Cadence

Per the same 2026-11-11 registry fetch: nineteen of the twenty-one evenings from 10-22 to 11-11 carry at least one dshmarket release. Quiet 10-25 is no longer the only gap — 11-10 is the second — and 11-11 counts exactly one version at the fetch (16:49:38 UTC). The dsh-market release page is still authored by the repo’s github-actions bot rather than a human account.

Nine changes, seven authors, three first-timers

Cadence

More in this series