|
|
|
@@ -62,11 +62,33 @@ because otherwise there would be no way to grant anything at all.
|
|
|
|
|
|
|
|
|
|
## Install
|
|
|
|
|
|
|
|
|
|
From the repository, following releases:
|
|
|
|
|
|
|
|
|
|
```sh
|
|
|
|
|
dsh plugin --profile web add "/path/to/dsh-facet"
|
|
|
|
|
dsh plugin --profile web add "git+https://git.notexpectedyet.com/Not-Expected-Yet/dsh-facet.git#semver:^0.1.0"
|
|
|
|
|
dsh --profile web --dump-config | grep preset-facet # expect the row
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
Or from a checkout, while working on the plugin itself:
|
|
|
|
|
|
|
|
|
|
```sh
|
|
|
|
|
dsh plugin --profile web add "/path/to/dsh-facet"
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
The `#semver:^0.1.0` fragment is the difference between an install that can be
|
|
|
|
|
updated and one that cannot. Leave it off and pnpm resolves the default branch to
|
|
|
|
|
a **commit** and records that commit in `pnpm-lock.yaml` — `dsh plugin update`
|
|
|
|
|
then has no version to move to, because there is nothing to move between. With
|
|
|
|
|
the fragment, pnpm resolves against the repository's tags, which the release
|
|
|
|
|
workflow creates on every push to `master`. The fragment needs a tag to resolve
|
|
|
|
|
against, so it only works once the first release has been published.
|
|
|
|
|
|
|
|
|
|
Either way the command is `pnpm add` run inside the profile, and it registers the
|
|
|
|
|
bundle in `dsh.profile.bundles` for you. A git-hosted plugin that builds on
|
|
|
|
|
install can be blocked by pnpm's build policy; add the key pnpm asks for under
|
|
|
|
|
`allowBuilds` in the profile's `pnpm-workspace.yaml`. This bundle ships sources
|
|
|
|
|
with no build step, so it does not trip that.
|
|
|
|
|
|
|
|
|
|
The bundle contributes two layers:
|
|
|
|
|
|
|
|
|
|
- **`cordis.patch.yml`** — the host row `facet-policy`, which owns the mode and
|
|
|
|
|