From 147227bb3cd53d6eeb5fb20f0e8c807916b64c7d Mon Sep 17 00:00:00 2001 From: Plugin Dev Date: Thu, 1 Oct 2026 08:55:07 +0100 Subject: [PATCH] docs: switch install to the git+https #semver: convention used by the other profile plugins --- README.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/README.md b/README.md index 19ce28a..44a1ff8 100644 --- a/README.md +++ b/README.md @@ -21,13 +21,13 @@ Nothing is ever clobbered: a pre-existing system Chrome or a user wrapper keeps ## Install (from git — recommended) -Install from your forge (the command below is the full-URL form for any host; on GitHub you can use the shorthand `github:/dsh-browser-install#master`): +This repo lives on `git.notexpectedyet.com`, so the install uses the same `git+https://…#semver:` convention as the other plugins in the profile (`dsh-facet`, `dsh-recall`, `dsh-slopo`). On GitHub the equivalent shorthand would be `github:/dsh-browser-install#semver:^0.1.0`: ```sh -dsh plugin --profile web add https://git.notexpectedyet.com/Not-Expected-Yet/dsh-browser-install.git#master +dsh plugin --profile web add "git+https://git.notexpectedyet.com/Not-Expected-Yet/dsh-browser-install.git#semver:^0.1.0" ``` -- The `#master` **branch ref is what makes updates work**: `pnpm update` re-resolves the branch tip (verified against pnpm 12.8.1), so after you push new commits simply run +- The **`#semver:^0.1.0` ref is what makes updates work**: it resolves against the repo's version tags (each release is a `v` tag), and `pnpm update` moves the dependency within the range. This mirrors exactly how `dsh-facet`/`dsh-recall`/`dsh-slopo` are kept current in this profile. To publish a new version: bump `version` in `package.json`, commit, tag it, push — then run ```sh dsh plugin --profile web update # all deps @@ -36,7 +36,7 @@ dsh plugin --profile web add https://git.notexpectedyet.com/Not-Expected-Yet/dsh - Bundle changes only become active after a profile restart: `dsh --profile web`. - No build step: the bundle ships plain ESM and declares no `prepare` script, so pnpm's default block on git-dependency build scripts never applies — nothing to `allowBuilds` in `pnpm-workspace.yaml`. -- pnpm installs git deps over HTTPS, so keep the repo public (or set up credentials on the host). +- pnpm resolves git deps over HTTPS, so **the repo must be public** on the forge (or the DSH host needs git credentials). A private/new repo makes `git ls-remote` fail with "could not read Username ... terminal prompts disabled", which is what a bare `#master` install hit here. ## Alternative: install from a local checkout