# Publishing the standalone DSH Plugin Manager

This directory is the independent, publish-ready repository. The root package is already shaped as a DSH bundle: it declares `dsh.bundle.patch`, declares the browser `dsh.client` face, and contains verified Host/Client artifacts under `lib/`.

## Before publishing

1. Choose the final npm package name. The default `dsh-plugin-manager-community` is intentionally generic. If it is not the name you want, run:

   ```sh
   node scripts/rename-package.mjs @your-scope/dsh-plugin-manager https://github.com/your-account/dsh-plugin-manager
   ```

2. Review `package.json`, especially `repository`, `version`, author information (if you add it), peer dependency ranges, and the package name in `cordis.patch.yml`.
3. Run the artifact check:

   ```sh
   node scripts/verify-distribution.mjs
   npm pack --dry-run
   ```

   The dry-run must include `lib/index.js`, `lib/client.js`, `lib/remote.js`, `lib/invariant.js`, the declaration files, `cordis.patch.yml`, and the README files. It must not contain `workspace:` dependency ranges.

## Publish to npm

Authenticate with the account that owns the selected scope/name, then publish the root package:

```sh
npm whoami
npm publish --access public
```

Do not publish the parent Harness monorepo for this plugin. This folder is the package root that users install.

## Publish the GitHub discovery page

Create a public GitHub repository whose root is this directory. Push the same files, then add the `dsh-plugin` topic. The topic is only the market-discovery index; npm remains the normal install/update channel.

If users may install directly from GitHub, publish semver Releases such as `v0.1.2`. The manager checks the latest semver Release for GitHub dependencies, including commit-pinned installs; an unpinned source without a usable semver Release falls back to the repository head. Non-semver Release names cannot be compared safely as versions.

The repository root must keep these files together:

- `package.json`
- `cordis.patch.yml`
- `lib/index.js`
- `lib/client.js`
- `lib/remote.js`
- `README.md` and `README.zh.md`

## Smoke test after publishing

Use a disposable profile or the intended Web profile:

```sh
npx -y @deepseek-ai/dsh plugin --profile web add <published-package-name>@<version>
npx -y @deepseek-ai/dsh web
```

Open **Settings → Plugins**. The Plugin manager tab should appear above the installed inventory. Search for `dsh-better-sidebar` or `modlens`; the market result should display the npm install target when the repository publishes one.

When testing **Restart now** in the native Web profile, the process replaces itself. The triggering browser request may be reported as `Failed to fetch`; this is expected only when the new Web process comes back and the updated `lib/client.js` shows the reconnecting status. Keep `lib/index.js` and `lib/client.js` from the same package release.

If pnpm reports an ignored native build (for example a dependency such as `node-pty`), review the exact package and approve only the reported build key before retrying. A GitHub source install can additionally trigger the package's `prepare` script; that is why ordinary users should receive the published npm tarball.

## Versioning

Bump the root package version for every release. The manager's startup check uses pnpm's registry metadata for npm-installed packages. Keep the package's DSH peer dependency range aligned with the DSH release you support.