dsh plugin prepare errors under package managers

A dsh plugin that reports reading 'prepare' during installation is usually describing a build step that never ran, not a bug in the plugin's runtime code. DeepSeek Harness installs pass through npm, pnpm or yarn, and each one decides differently whether lifecycle scripts are allowed to execute. The failure looks like a code error because the message is printed by code that expected generated files to exist.

What a dsh plugin prepare step is doing

The prepare stage compiles or generates the files that the plugin will load later, so skipping it leaves a package that resolves but cannot run.

An install moves through several stages: resolve dependencies, download packages, run build scripts and link the result into the dependency tree. Prepare sits in the build part, after the source arrives and before the package is treated as usable. The plugin does not need to know which package manager is running, but it does depend on this stage completing.

For a plugin distributed as source, prepare may compile TypeScript, generate an entry file or copy static assets. The published tarball can also include a prepare script that runs on install. Either way, the output is what the loader reads, and the output is what disappears when the stage is blocked.

The log wording makes the failure look like a property read on an undefined object. In practice, the install script was interrupted or skipped, and the later read found nothing. Separating the stage from the symptom is the first step toward a fix.

This is why editing the plugin source rarely helps. The source may be perfectly valid while the installer never executed the command that turns it into a loadable package. Look at what the installer decided before you look at what the plugin contains.

Why package-manager approval blocks a DeepSeek Harness plugin build

Modern package managers can require explicit approval before dependency scripts run, and an unapproved plugin is installed without its build output.

The approval model exists to reduce supply-chain risk. A package that runs arbitrary code during install is convenient for native modules and build steps, but it is also a path for malicious scripts. pnpm made this trade-off visible by requiring approval for dependency builds, and other managers expose similar switches.

When the plugin is not on the approved list, the installer does not fail loudly at the decision point. It records the build as ignored and continues, and the first obvious error appears later when something tries to read the missing output. That delay is why the log looks like a runtime problem.

npm error code 1
npm error path .../node_modules/<package>
npm error command sh -c prepare
npm error Error: Cannot read properties of undefined (reading 'prepare')
npm error A complete log of this run can be found in ...

The same final line can appear from three different decisions: scripts disabled, build not approved or cache reused from a failed run. The surrounding log lines carry the decision, so read the middle of the log rather than only the final stack. A line that says ignored or skipped is more useful than the stack that follows it.

A DeepSeek Harness plugin installed through a restricted policy is therefore a package without its generated files. The fix is to approve the build or change the policy for that package, then reinstall so the skipped stage actually runs. The DSH Plugin Hub entry often names the build requirements next to the package.

Checking an npm dsh plugin prepare failure

npm runs lifecycle scripts by default, so a silent skip usually means a configuration switch or a damaged cache.

Check the project and global configuration for script suppression first. A hardened environment may disable scripts globally, which is a reasonable security choice but incompatible with plugins that must build. If that switch is on, approve the package or install it in an environment where scripts are allowed.

Read the install log around the prepare stage, not just the final error. You want to know whether the command was invoked at all. An invoked command that fails points at missing dependencies, while a command that never appears points at policy.

Clear the cache and reinstall when the log suggests a cached package. A previous failed build can leave a partial directory that npm happily reuses. Removing the cache costs a download and often removes the confusing state in one step.

Pin the version once the install works. Version drift can introduce a new prepare script or a new dependency without warning, and a pinned version keeps the working combination stable. Record the npm version too, since script defaults change across majors.

Checking a pnpm DSH plugin build approval

pnpm makes the approval decision explicit, so the first check is whether the plugin package is allowed to build at all.

Inspect the approval configuration for the project and for the current pnpm version. A package that is absent from the approved set is skipped, even if everything else about the install is correct. The approval command can add it, and the exact name varies with the pnpm release.

After approving, clear the store entry for that package and reinstall. pnpm caches build results, and an unapproved run may have left an empty or partial artifact. Reinstalling without clearing can reproduce the same state and make the approval look ineffective.

The linking layout is another pnpm-specific factor. Packages are not hoisted the same way as in npm, so a build that assumes a sibling dependency can fail even when the dependency is installed. Read the build error rather than translating an npm fix directly.

Pin the pnpm version for the project when the policy matters. Approval behaviour and configuration keys have changed across major releases, and a teammate on a different version can reproduce a failure you cannot see. The version is part of the environment, not a detail.

Checking a yarn DeepSeek Harness plugin install

Yarn splits between classic and modern releases, so the same prepare error can come from two different script policies.

Identify the yarn version before reading the log. Classic yarn executes lifecycle scripts more freely, while modern yarn can restrict them through configuration. A fix copied from a classic project may not apply to a Berry workspace.

Check the cache next, because yarn stores build output and can reuse a failed result. Clear the relevant cache entry and reinstall the package. If the error disappears, the original problem was a partial artifact rather than the current script.

Hoisting is the other common difference. A plugin that imports a package it expects to find at the top level can work under one installer and fail under another. The build error usually names the missing module, which tells you whether hoisting is involved.

Read yarn's own log format rather than parsing an npm guide. The messages and the location of the useful context differ enough that a translated fix wastes time. Once the version, cache and hoisting are checked, the remaining cause is usually the package itself.

What a blocked dsh plugin prepare leaves to inspect

The error text is the last event, so the useful evidence sits in the decisions that came before it.

Read the log from the middle, where the installer records whether it ran, skipped or reused the build. That decision tells you which policy to inspect and which cache to clear. The final stack only confirms that the output was missing.

1. Identify the package manager and its exact version.
2. Find the prepare stage in the log and note whether it ran.
3. Check npm script settings, pnpm build approval or yarn script policy.
4. Confirm that dependencies needed by the build are installed.
5. Clear the relevant cache or store entry for the package.
6. Reinstall and confirm that generated files now exist.
7. Record the working installer version and the policy that allowed the build.

If all three installers fail in the same way, move the package out of the installer path for a test. A local tarball or a pinned release can show whether the package itself is incomplete. When the tarball works, the problem is policy; when it fails too, the problem is the artifact.

The habit that keeps this short is to ask three questions in order: was the build called, who stopped it, and what did it leave behind. Those answers cover npm, pnpm and yarn without memorising each manager's syntax, and they apply to other DSH plugins that compile during install. The next blocked build becomes a known pattern instead of a new mystery.