Repository navigation
Releases: tcgbp/dsh-flash-proxy
Release list
dsh-flash-proxy 0.1.5
dsh-flash-proxy 0.1.5 — follows the panel core to dsh-flash
The host panel moved out of the retired single package dock-flash@2.x into the
dsh-flash core package, and the dock-base Workbench integration into the
dock-flash@3.0.0 adapter. This release re-points the host contract:
dsh.client.injectnow namesdsh-flash— a client module graph row's id is its package name, so this is what makes the core's client half load first.- the peer dependency is now
dsh-flash: >=1.0.0-0 <2.0.0-0. - the READMEs and the market entry name the
dsh-flashcore.
Unchanged on purpose: the dock-flash:* switch ids, the dock-flash settings
namespace (the profile entry id deliberately stayed dock-flash), the
quickControl service and the /plugins/dock-flash/… routes.
This is the system proxy plugin: it does not attach to the panel, but it declares the same host contract.
Tarball: dsh-flash-proxy.tgz (this release), matching docs/tcgbp__dsh-flash-proxy.yml.
v0.1.4
v0.1.3
This plugin had no dock-flash peer at all, although it registers its five switches through
dock-flash's quickControl registry, discovers dock-flash through the dock-flash:ready event,
and ships a one-time migration out of dock-flash's own proxyMode/testUrl settings. A missing
peer means npm has no opinion about the base plugin's version — and a version that is too old
fails at runtime, silently, instead of at install time.
The floor is 1.0.15, taken from what its rows actually use: hideLabel is 1.0.15, cluster
1.0.14, subtitleBlock/visible 1.0.11, the log fields (getMeta, hideWhenEmpty)
1.0.7/1.0.10 — while the registry and the ready event it discovers through both date to 0.16.0.
The range carries one branch per tuple whose prereleases must resolve, the form this family
states:
">=1.0.15-0 <2.0.0-0 || >=2.0.0-0 <3.0.0-0"
Both directions are asserted: 1.0.15, 2.0.2 and 2.0.0-rc.1 resolve; 1.0.14 and 3.0.0-0
do not. Then verified for real by installing the packed tarball beside dock-flash@2.0.2 — no
ERESOLVE.
This release carries the peer fix only.
v0.1.2
settings.describe() is not always a promise — in both halves, and the host one never worked.
settings.describe() was called with .then(...) unconditionally, but that one name has
two implementations: the typert WIRE form returns a Promise, while the DIRECT form —
SettingsController.describe() in @deepseek-ai/dsh-api-settings-controller — is
synchronous and returns the view object itself, and can throw instead
(settings service is absent: mount @deepseek-ai/dsh-settings).
The resulting TypeError: settings.describe(...).then is not a function is raised
synchronously, so it escaped before the .catch at the end of the loader's chain.
This plugin's apply() is async with no internal try/catch, so the throw rejected apply — and a
failed apply fails the Cordis fiber: the plugin never activates and its five switches silently never
appear.
The HOST half was worse. Its migration (ctx.inject(['settings'], …)) reads the HOST service —
SettingsForms from @deepseek-ai/dsh-settings — whose describe() is synchronous and returns the
descriptor array, not a {ok, value} envelope. settings.describe().then(...) therefore threw on
the spot, and because the throw happens at the .then access it escaped the .catch(() => {}) at
the end of that chain: the dock-flash → dsh-flash-proxy settings migration has never run once. Now
normalized, and it accepts both shapes.
Both call sites now normalize through _describeAsync(), which accepts a Promise, a plain view, or a
throw, so the loader's existing .catch handles it instead of the plugin dying.
Hardening, in the same release. apply() had no internal try/catch, so any throw inside it
rejected the async apply — and a failed apply fails the Cordis fiber: the plugin never activates
and its switch silently never appears. The body is unchanged and now lives in _applyInner; the public
apply reports the failure (apply failed (non-fatal)) and returns, exactly as dock-flash's has always
done.
Patch: no published surface changed.