dsh-wsl-tool 1.10.0 → 1.10.1

package/PUBLISHING.md

@@ -67,6 +67,22 @@ both that the entry stays relative and that it resolves.
    once at load. A patch change (the tool row, or the sidebar terminal override)
    is read at composition time, so it needs that restart too.
 
+   **Then prove the schema really builds from the installed copy**, because this
+   is the one failure the tools survive:
+
+   ```sh
+   cd ~/.dsh/profiles/desktop/node_modules/dsh-wsl
+   node -e "import('./index.js').then(m => console.log(typeof m.Config, JSON.stringify(m.Config({}))))"
+   ```
+
+   It must print `function` and the resolved defaults. If it prints `undefined`,
+   the plugin declares no `Config`, the platform has no schema to project, the
+   entry's config status stays `absent` and the sidebar panel renders without a
+   single switch while all three tools keep working. The fragile step is the
+   interop hop: `@deepseek-ai/schemastery` exports its builder as the **default**
+   export, so `const { Schema } = await import(...)` silently yields `undefined`
+   (see `lib/schema.js`, and the regression test that pins the picking).
+
 3. The tag runs the pipeline. The order is deliberate — the release asset goes
    **first** because it is the market's critical path, then npm, so a failing npm
    publish fails the run loudly without withholding the release.

package/index.js

@@ -22,6 +22,7 @@
 // every switch below is consulted once, in `apply`.
 
 import { resolveConfig } from './lib/config.js'
+import { pickSchemaBuilder } from './lib/schema.js'
 import { createRunner } from './lib/runner.js'
 import { createWslTool } from './lib/tools/wsl.js'
 import { createWslPathTool } from './lib/tools/wsl-path.js'
@@ -31,18 +32,29 @@ export const name = 'tool-wsl'
 export const inject = ['tools', 'subprocess']
 
 // The schema is what gives this plugin a settings surface at all: the platform
-// derives the namespace the sidebar panel writes to from the entry's id plus this
-// schema. It needs `@deepseek-ai/schemastery`, which a real DSH profile supplies
-// (the plugin declares it as an optional peer dependency) but which is absent when
-// this module is imported standalone, as `test/smoke.mjs` does. A soft import
-// keeps the tools runnable there: without a schema every switch keeps its default
-// and only the panel is missing.
+// projects the config of every entry that declares one (`ctx.settings.describe()`
+// is keyed by entry id), and the sidebar panel reads and writes that projection.
+// It needs `@deepseek-ai/schemastery`, which a real DSH profile supplies (the
+// plugin declares it as an optional peer dependency) but which is absent when this
+// module is imported standalone, as `test/smoke.mjs` does. A soft import keeps the
+// tools runnable there: without a schema every switch keeps its default and only
+// the panel is missing — and `lib/schema.js` explains why the PICKING, not just
+// the import, is the fragile part.
 let Schema = null
 try {
-  ({ Schema } = await import('@deepseek-ai/schemastery'))
+  Schema = pickSchemaBuilder(await import('@deepseek-ai/schemastery'))
 } catch {
   Schema = null
 }
+if (Schema === null) {
+  // Not fatal — the tools run on their defaults — but it is exactly the difference
+  // between a panel with switches and one without, so say so instead of failing
+  // quietly.
+  console.warn(
+    'dsh-wsl-tool: no schema builder (@deepseek-ai/schemastery) — the tools run on ' +
+    'their defaults and the sidebar panel will not offer the switches',
+  )
+}
 
 /**
  * The plugin's own configuration.

package/lib/schema.js

@@ -0,0 +1,35 @@
+// The schema builder behind `Config`, resolved through one interop hop.
+//
+// `@deepseek-ai/schemastery` exports the builder as its DEFAULT export: the module
+// namespace of `import('@deepseek-ai/schemastery')` is `{ default: Schema }`, with
+// no named `Schema`. Code that destructures `{ Schema }` from it gets `undefined`
+// without any error, and `Schema?.object({...})` then yields `undefined` — so the
+// plugin declares no `Config`, the platform has no schema to project, its settings
+// namespace never appears, and the sidebar panel renders without switches. That is
+// a quiet failure two layers away from its cause (measured: the Loader entry's
+// config status stayed `absent` while the tools themselves worked), so the shape is
+// pinned here, in one place, with a unit test.
+//
+// A named `Schema` export and a `Schema` property on the default are accepted too:
+// other DSH packages re-export the builder in those shapes, and the check below is
+// about what can actually build a schema, not about this one package.
+
+/**
+ * Pick the schema builder out of a module namespace.
+ *
+ * @param namespace - a module namespace (`await import(...)`), or anything else.
+ * @returns the builder, or null when the namespace carries none.
+ */
+export function pickSchemaBuilder(namespace) {
+  if (namespace === null || typeof namespace !== 'object') return null
+  const candidates = [namespace.Schema, namespace.default?.Schema, namespace.default]
+  for (const candidate of candidates) {
+    // `object` is the entry point every Config needs; requiring it here is what
+    // makes a wrong export shape look like a missing builder instead of a schema
+    // that throws later, while the composition is already being built.
+    if (candidate !== null && candidate !== undefined && typeof candidate.object === 'function') {
+      return candidate
+    }
+  }
+  return null
+}

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "dsh-wsl-tool",
-  "version": "1.10.0",
+  "version": "1.10.1",
   "description": "Run Linux commands from Windows through WSL, essentially matching a native Linux DSH for command execution: background jobs, stdin, path translation, a destructive-command guard and a WSL capability report. A left-sidebar panel switches each capability on or off, each with a one-line explanation, and an opt-in patch gives the desktop app's sidebar terminal a WSL shell. WSL calls run below the DSH sandbox, and a project on a Windows drive keeps Windows filesystem semantics.",
   "type": "module",
   "main": "index.js",