Fix slow DSH plugin market downloads with an npm mirror

A slow or half-finished DSH plugin install has three possible causes: a slow route to the registry, a lagging npm mirror, or a plugin whose native dependencies must compile. The symptoms look alike but the fixes differ, so this guide classifies first, then configures mirrors and proxies, then retries cleanly and verifies.

Step 1: classify the DSH plugin install symptom first

When an install fails, the line where the output stops tells you which class of problem you have. The comparison:

For a full reading of that error code see DSH plugin install failure: ERR_PNPM_FETCH_404; this article only handles slow and interrupted installs.

Step 2: configure mirrors and proxies for DSH plugin installs

Mirror and proxy settings live in .npmrc, and because dsh plugin installs are driven by pnpm, which reads the same file, one change covers both entry paths (source). Five steps:

1. See which source is in use — run npm config get registry. Expected: it prints the current registry, so you can tell whether a mirror is configured.
2. Switch to a faster mirror — run npm config set registry https://registry.npmmirror.com. Expected: the next plugin install downloads noticeably faster.
3. Override the source for one install — append a flag instead of changing global config:

dsh plugin --profile web add <package> --registry=https://registry.npmjs.org

Expected: that install uses the named source; use this to check whether the official registry really has the package when you see a 404. npm_config_registry=https://registry.npmjs.org dsh plugin --profile web add <package> does the same for one command.

4. Go through a proxy on a corporate network — run npm config set proxy http://127.0.0.1:<port> and npm config set https-proxy http://127.0.0.1:<port>. Expected: installs stop timing out; HTTP_PROXY / HTTPS_PROXY environment variables scope the same setting to one shell.
5. Confirm the proxy allows plugin source domains — both the npm registry and GitHub must be reachable. Expected: github:owner/repo sources no longer stall while fetching.

Clicking Install in the plugin market follows the same fetch path, so a corrected mirror and proxy speed up the interface too.

Step 3: retry the DSH plugin install after cleanup and verify

When an install fails halfway, uninstall rather than deleting directories, so declarations and files stay in agreement. Four steps:

1. Remove the failed entry — run dsh plugin --profile web remove <package>. Expected: the command returns successfully and the profile's dependency record no longer lists it.
2. Confirm you are on the right profile — run ls "$DSH_HOME/profiles". Expected: it matches the profile you intended, so the reinstall does not land elsewhere.
3. Reinstall against the new source — run dsh plugin --profile web add <package>. Expected: it completes in a reasonable time without stalling.
4. Verify in two places — run dsh plugin --profile web list, then check Settings → Plugin Market → Installed. Expected: both show the plugin and agree on the version.

The installed list in the plugin market is the final judge; the command output has to agree with it. See using the plugin market for browsing and versions.

Notes and limits for slow DSH plugin installs

1. Mirrors are fast but lag: a freshly published plugin or version may be missing from a mirror and fail with an immediate 404; the test is whether the official registry lists the same name.
2. Proxies must allow two kinds of domains: both the registry and the plugin source, such as GitHub, have to be reachable or the install stalls halfway.
3. Do not delete directories instead of uninstalling: manual deletion leaves declarations and files out of sync; use remove and add.
4. A build stall is not a network problem: gyp or make output means a toolchain issue, so switching mirrors will not help.
5. Classify before acting: slow, 404 and build stalls need different fixes, and blind reinstalls repeat the same mistake.

Sources: dsh CLI README, npm .npmrc configuration, dshplugin/dsh-plugin-hub