dsh-plugin-toolkit 0.7.1 → 0.7.3

package/CHANGELOG.md

@@ -1,3 +1,29 @@
+## 0.7.3
+
+The scaffold was two minor versions behind the tool that wrote it.
+
+- `init` pins the toolkit it was generated by (`^<its own version>`) instead of
+  a number typed once, so `npm install` in a fresh scaffold gets the version
+  whose README you just read.
+- The generated workflow uses the composite action with `verify` instead of
+  `npx dsh-plugin-toolkit@0.5.0 doctor .` — `doctor` reads the working copy and
+  cannot see that `files` left the client bundle out.
+- `test/init.test.mjs` guards both: the pinned range must equal the running
+  version, and the workflow must not fall back to `doctor`.
+
+## 0.7.2
+
+`verify` runs from npx's cache, so it has to find jsdom and React where the
+plugin is, not where the tool is.
+
+- `testkit` resolves `jsdom`, `react` and `react-dom` from the plugin folder
+  first, then the working directory, then the tool's own dependencies.
+- `verify` passes the plugin folder through, so
+  `uses: WJDdidi-1/dsh-plugin-toolkit@v1` works in a workflow that ran `npm ci`
+  in the plugin: before this, the action failed with
+  `testkit needs a DOM: npm install --save-dev jsdom react react-dom` even
+  though the plugin declared them.
+
 ## 0.7.1
 
 The action now checks the tarball, which is the only thing a user installs.

package/README.md

@@ -169,7 +169,7 @@ AIignore No workspace yet Could not read the report …
 
 ## Start from the example
 
-[`dsh-plugin-example`](https://github.com/WJDdidi-1/dsh-plugin-example) is a ~70-line plugin: one sidebar tab, two languages, one behaviour test, CI that runs `doctor` through the composite action. It is the shape this toolkit expects, so it is also the fastest way to see whether the toolkit fits your plugin.
+[`dsh-plugin-example`](https://github.com/WJDdidi-1/dsh-plugin-example) is a ~70-line plugin: one sidebar tab, two languages, one behaviour test, CI that runs `verify` through the composite action. It is the shape this toolkit expects, so it is also the fastest way to see whether the toolkit fits your plugin. It is a GitHub template too: **Use this template** starts you on a plugin whose first publish already passes.
 
 ```sh
 dsh plugin add dsh-plugin-example

package/lib/init.mjs

@@ -6,7 +6,14 @@
  */
 import fs from 'node:fs';
 import path from 'node:path';
+import { fileURLToPath } from 'node:url';
 
+// The scaffold pins the toolkit it was generated by, not a number typed once:
+// a scaffold that installs two minor versions behind is the first thing a new
+// author sees and the last thing anyone updates.
+const VERSION = JSON.parse(
+  fs.readFileSync(path.join(path.dirname(fileURLToPath(import.meta.url)), '..', 'package.json'), 'utf8'),
+).version;
 const NPM_NAME = /^(?:@[a-z0-9][a-z0-9._-]*\/)?[a-z0-9][a-z0-9._-]*$/;
 
 export function checkName(name) {
@@ -29,7 +36,7 @@ function manifest({ name, title, version }) {
       files: ['index.js', 'client.js', 'cordis.patch.yml', 'README.md'],
       scripts: { test: 'node --test', doctor: 'dsh-plugin doctor .' },
       devDependencies: {
-        'dsh-plugin-toolkit': '^0.5.0',
+        'dsh-plugin-toolkit': `^${VERSION}`,
         jsdom: '^26.1.0',
         react: '^18.3.1',
         'react-dom': '^18.3.1',
@@ -136,7 +143,7 @@ export function files({ name, title = 'My panel', version = '0.1.0' }) {
     'test/panel.test.mjs': test({ name, title }),
     'README.md': `# ${slug}\n\n${title} — a panel for DeepSeek Harness.\n\n## Requirements\n\n| What | Version | Why |\n| --- | --- | --- |\n| DeepSeek Harness | >= 0.2.0 | provides \`sidebarRightTabs\` |\n| Node | >= 18 | the host half |\n\n## Develop\n\n\`\`\`sh\nnpm install\nnpm test            # mounts client.js in Node\nnpm run doctor      # checks the manifest before you publish\n\`\`\`\n\n## Install\n\n\`\`\`sh\ndsh plugin add ${name}\n\`\`\`\n`,
     '.gitignore': 'node_modules/\n',
-    '.github/workflows/ci.yml': `name: ci\n\non:\n  push:\n    branches: [main]\n  pull_request:\n\njobs:\n  test:\n    runs-on: ubuntu-latest\n    strategy:\n      matrix:\n        node: [18, 20, 22]\n    steps:\n      - uses: actions/checkout@v4\n      - uses: actions/setup-node@v4\n        with:\n          node-version: \${{ matrix.node }}\n      - run: npm install\n      - run: npm test\n      - run: npx --yes dsh-plugin-toolkit@0.5.0 doctor .\n`,
+    '.github/workflows/ci.yml': `name: ci\n\non:\n  push:\n    branches: [main]\n  pull_request:\n\njobs:\n  test:\n    runs-on: ubuntu-latest\n    strategy:\n      matrix:\n        node: [18, 20, 22]\n    steps:\n      - uses: actions/checkout@v4\n      - uses: actions/setup-node@v4\n        with:\n          node-version: \${{ matrix.node }}\n      - run: npm install\n      - run: npm test\n      # verify, not doctor: doctor reads the working copy, so a \`files\` list\n      # that forgets client.js passes it and the installed plugin has no panel.\n      - uses: WJDdidi-1/dsh-plugin-toolkit@v1\n        with:\n          dir: .\n          version: ${VERSION}\n`,
   };
 }
 

package/lib/testkit/env.mjs

@@ -6,15 +6,34 @@
  * jsdom plus the real React gives us the same arrangement in Node, which is what
  * makes panel behaviour assertable in CI instead of by hand.
  */
-let JSDOM;
-let VirtualConsole;
-try {
-  ({ JSDOM, VirtualConsole } = await import('jsdom'));
-} catch {
-  throw new Error('testkit needs a DOM: npm install --save-dev jsdom react react-dom');
+import { createRequire } from 'node:module';
+import path from 'node:path';
+import { fileURLToPath } from 'node:url';
+
+/**
+ * Resolve a dependency the way the *plugin under test* would.
+ *
+ * `npx dsh-plugin-toolkit verify` installs the tool in npx's own cache, so a
+ * bare `import('jsdom')` looks there and not in the project that declared it.
+ * The plugin folder is the authority on what is installed.
+ */
+export function requireFrom(name, resolveFrom) {
+  const anchors = [resolveFrom, process.cwd(), path.dirname(fileURLToPath(import.meta.url))]
+    .filter((anchor) => typeof anchor === 'string' && anchor !== '');
+  for (const anchor of anchors) {
+    try {
+      return createRequire(path.join(anchor, 'noop.js'))(name);
+    } catch {
+      // Try the next place a dependency could legitimately live.
+    }
+  }
+  throw new Error(
+    `testkit needs ${name} where the plugin is installed: cd ${anchors[0]} && npm install --save-dev jsdom react react-dom`,
+  );
 }
 
-export function createDom({ html = '<!doctype html><html><body><div id="root"></div></body></html>' } = {}) {
+export function createDom({ html = '<!doctype html><html><body><div id="root"></div></body></html>', resolveFrom } = {}) {
+  const { JSDOM, VirtualConsole } = requireFrom('jsdom', resolveFrom);
   // jsdom's CSS parser predates nesting and `:has()`, so it complains about
   // stylesheets it cannot parse. That is a jsdom limit, not a panel bug.
   const virtualConsole = new VirtualConsole();

package/lib/testkit/mount.mjs

@@ -4,7 +4,7 @@
  * The helpers are deliberately blunt — click, type, press — because that is the
  * vocabulary a bug report uses. Anything cleverer hides which selector was hit.
  */
-import { createDom, installGlobals } from './env.mjs';
+import { createDom, installGlobals, requireFrom } from './env.mjs';
 import { createHost } from './host.mjs';
 import { loadBundle } from './load.mjs';
 import { compare, write } from './snapshot.mjs';
@@ -37,24 +37,29 @@ export async function mountClient(options) {
     container = 'root',
   } = options;
 
-  const { dom, window, document } = createDom();
+  // React is resolved from the plugin's folder too: when the tool runs from
+  // npx's cache, its own dependencies are not the ones the panel was written
+  // against.
+  const resolveFrom = options.resolveFrom ?? process.cwd();
+  const need = (name) => requireFrom(name, resolveFrom);
+
+  const { dom, window, document } = createDom({ resolveFrom });
   const restoreGlobals = installGlobals(window, document);
 
-  const need = async (name) => {
+  const React = need('react');
+  const reactDom = need('react-dom/client');
+  const jsxRuntime = need('react/jsx-runtime');
+  const jsxDevRuntime = (() => {
     try {
-      return await import(name);
+      return need('react/jsx-dev-runtime');
     } catch {
-      throw new Error(`testkit needs ${name}: npm install --save-dev jsdom react react-dom`);
+      return jsxRuntime;
     }
-  };
-  const React = await need('react');
-  const reactDom = await need('react-dom/client');
-  const jsxRuntime = await need('react/jsx-runtime');
-  const jsxDevRuntime = await import('react/jsx-dev-runtime').catch(() => jsxRuntime);
+  })();
 
   const modules = {
     react: React.default ?? React,
-    'react-dom': await import('react-dom'),
+    'react-dom': need('react-dom'),
     'react-dom/client': reactDom.default ?? reactDom,
     'react/jsx-runtime': jsxRuntime,
     'react/jsx-dev-runtime': jsxDevRuntime,

package/lib/verify.mjs

@@ -121,7 +121,9 @@ export async function verify({ dir, mount = true }) {
     }
     try {
       const { mountClient } = await import('./testkit/index.mjs');
-      const panel = await mountClient({ file: entryFile });
+      // Resolve jsdom/React from the plugin's own folder: `verify` may be
+      // running out of npx's cache, whose dependencies are not the panel's.
+      const panel = await mountClient({ file: entryFile, resolveFrom: dir });
       const text = panel.text();
       await panel.unmount();
       return { ok: true, stage: 'mount', failures: [], files: packed.files, size: packed.size, installed, text };

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "dsh-plugin-toolkit",
-  "version": "0.7.1",
+  "version": "0.7.3",
   "description": "Preflight, release and test DeepSeek Harness plugins: checks what the host needs, waits for npm to actually serve the version, and keeps the market index honest.",
   "type": "module",
   "bin": {