docs: switch install to the git+https #semver: convention used by the other profile plugins

This commit is contained in:
Plugin Dev committed 2026-10-01 08:55:07 +01:00
1 parent 4068f2a30f
commit 147227bb3c
1 file changed
+4 -4
+4 -4
View File
@@ -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:<you>/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:<you>/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<version>` 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