Fix ERR_REQUIRE_ESM and duplicate dsh-tools instance in DSH plugin

ERR_REQUIRE_ESM in a DSH plugin means it was compiled to CommonJS yet depends on an ESM-only package; reading 'prepare' of undefined means @deepseek-ai/dsh-tools was installed twice and symbol lookups conflict. Fix the first with an ESM build, the second by deduplicating dependencies; when it keeps failing, switch to a published build on DSH Plugin Hub.

DSH plugin build errors: an ESM loading conflict and prepare on undefined

ERR_REQUIRE_ESM is a module format conflict (CJS requiring an ESM-only package); reading 'prepare' of undefined is a duplicate-instance conflict (the tool package installed twice). The two messages (source):

1. ERR_REQUIRE_ESM — Node throws while loading the plugin: CommonJS code requires a package that only offers ESM exports; it triggers when the plugin build output is CJS yet depends on an ESM-only package (typically @deepseek-ai/dsh-tools);
2. reading 'prepare' of undefined — at runtime the plugin reads prepare on undefined; it triggers when two copies of @deepseek-ai/dsh-tools exist, internal symbol-key lookups fail and tool dispatch crashes;
3. Judgment: the first is a build-format problem, the second a dependency-instance problem — both are plugin-side defects; users cannot fix the source but can switch to a published build.

Why DSH plugin builds break: wrong module format, dsh-tools duplicated

Two roots: the plugin build output has the wrong module format (CJS against an ESM-only dependency blows up), and dsh-tools is loaded by multiple instances (the peer dependency was not singularized). In detail:

1. Module format mismatch: a plugin must be built as ESM ("type": "module") — dshbase states this rule explicitly (source); Node's ESM rules say ESM-only packages can only be loaded by ESM code (source), so a CJS build throws ERR_REQUIRE_ESM;
2. Duplicate instances: the plugin's peer dependency pulls a second @deepseek-ai/dsh-tools into the tree; the two instances use their own symbol keys for internal lookups and tool dispatch cannot find each other (source);
3. The fix belongs to the author: build config and peer ranges live inside the plugin package; on the user side the only levers are reinstalling to trigger dependency hoisting, or switching to a published build.

Fix DSH plugin build errors: switch to ESM, deduplicate, reinstall and verify

The author side changes the build and dependency declarations; the user side reinstalls to trigger dedupe, or directly switches to a hub-published build. Steps:

1. Switch to an ESM build (author side) — declare the module type in the plugin's package.json:
   json

   {
     "type": "module"
   }
   

   Emit ESM output (import/export instead of module.exports); with tsup/rollup set the format to 'esm', rebuild and publish (source);
2. Deduplicate dependencies (user side) — first check that dsh-tools appears exactly once in the profile:
   bash

   dsh plugin --profile web list
   grep -c '"@deepseek-ai/dsh-tools"' ~/.dsh/profiles/web/package.json
   

   An output greater than 1 means two copies — uninstall the related plugins and reinstall so pnpm hoists the peer dependency to a single instance;
3. Reinstall and verify — dsh plugin --profile web remove <package>, then add again, restart the host, and confirm ERR_REQUIRE_ESM or reading 'prepare' of undefined no longer appears;
4. Switch to a published build (fallback) — if it repeatedly fails to activate, go to Settings → Plugin Market (DSH Plugin Hub) and install a verification-passed published build — build problems are the classic git-distribution pitfall, and hub builds have already passed checks.

How to verify a DSH plugin build fix: single-copy dependency check and host load test

Do not just trust the install exit code — use pnpm why to confirm dsh-tools exists exactly once in the tree, then use the startup log to confirm both errors are gone and the plugin capability really works. In order:

1. Inspect the dependency tree to confirm dsh-tools is a single copy — run in the plugin workspace:

   bash

   pnpm why @deepseek-ai/dsh-tools
   

   One dependency chain in the output (e.g. dependencies: <plugin> > @deepseek-ai/dsh-tools) means dedupe worked; two or more chains mean it is still duplicated — back to step 2 of the fix section and reinstall.

2. Recheck that the profile declares it once:

   bash

   grep -c '"@deepseek-ai/dsh-tools"' ~/.dsh/profiles/web/package.json
   

   Output 1 means a single copy; more than 1 means the duplicate-instance problem is still there.

3. Check the plugin build format (author-side self-check) — confirm the plugin's package.json declares ESM:

   bash

   grep '"type"' <plugin-directory>/package.json
   

   Output "type": "module" means the format is correct; no such line means it is still CommonJS — back to step 1 of the fix section.

4. Restart the host and watch the startup log:

   bash

   dsh web
   

   No ERR_REQUIRE_ESM or reading 'prepare' of undefined during startup, and the log reaches the Web server listening line, means both errors are gone.

5. Trigger the plugin capability once — call a tool/command the plugin provides in the Web UI; a normal response means the plugin is really loaded into the host. If a new error appears (e.g. without inject), map it back to the corresponding section.

Notes: DSH plugin — switch to an ESM build

1. ERR_REQUIRE_ESM is a format problem; upgrading Node only helps some cases, the real fix is an ESM build by the plugin author.
2. For reading 'prepare' of undefined, check whether dsh-tools exists more than once in the tree first, then reinstall to trigger dedupe.
3. Both are plugin defects — do not try to bypass them by changing host config.
4. For git-distributed plugins with missing or wrongly-formatted build output, prefer the hub's published build.
5. See install error troubleshooting for other DeepSeek Harness install errors.

Sources: dshbase troubleshooting, Node.js ESM official docs, DeepSeek Harness plugin publishing docs