@mercury-fw/kit 0.40.0 → 0.42.0

package/CHANGELOG.md

@@ -1,5 +1,20 @@
 # @mercury-fw/kit
 
+## 0.42.0
+
+### Patch Changes
+
+- Updated dependencies [a7f2f13]
+  - @mercury-fw/channel-types@0.42.0
+  - @mercury-fw/plugin-types@0.42.0
+
+## 0.41.0
+
+### Patch Changes
+
+- @mercury-fw/plugin-types@0.41.0
+- @mercury-fw/channel-types@0.41.0
+
 ## 0.40.0
 
 ### Minor Changes

package/README.md

@@ -21,7 +21,7 @@ or anywhere else under the home, with `{ "path": ".my-cli" }` instead of `folder
 
 An app then runs `mfw credentials setup <plugin>`, which runs `setup` in a one-off container on the user's terminal, so the CLI asks for what it needs and writes its login straight onto a volume that keeps what the CLI writes back (a folder outside `~/.config` gets a link from its usual place to the volume). A CLI that authenticates any other way isn't covered by this, and neither is one that deletes its own folder and makes it again.
 
-A plugin also says whose identity its tools act with (`actsAs`). `"person"`: the person the turn is for, who logs in to the service through Mercury; the plugin contributes a `login` (`start` and `complete`, which `createCliPersonLogin` from `@mercury-fw/cli-engine` builds for a CLI with a two-step remote login), and its tools get the person and `requireLogin` in their context (`createCliTool` takes both, adds `--user` to every command and asks for the login when the CLI exits with code 3). `"mercury"`, or nothing declared: Mercury's own identity, whoever asks, which only someone allowed to make Mercury act as itself may use; that permission doesn't exist yet, so such a plugin is offered on the terminal only.
+A plugin also says whose identity its tools act with (`actsAs`). `"person"`: the person the turn is for, who logs in to the service through Mercury; the plugin contributes a `login` (`start` and `complete`, which `createCliPersonLogin` from `@mercury-fw/cli-engine` builds for a CLI with a two-step remote login), and its tools get the person and `requireLogin` in their context (`createCliTool` takes both, adds `--user` to every command and asks for the login when the CLI exits with code 3). `"mercury"`, or nothing declared: Mercury's own identity, whoever asks, which only someone allowed to make Mercury act as itself may use: a person holding `mercury.act-as-self` (every plugin) or `mercury.act-as-self.<plugin>` (that one), and the terminal. Those people also get each tool of a plugin acting as the person a second time, as `<tool>AsMercury`, run with Mercury's identity. Roles come from the directory the app declares (`DirectoryPlugin` in the channel contract: given who a channel says is talking, it returns the person and their roles, or `null` for someone it doesn't know).
 
 A proper workflow for writing plugins, with an SDK on top of these contracts, is planned ([#27](https://github.com/lucabro81/mercury-fw/issues/27)).
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@mercury-fw/kit",
-  "version": "0.40.0",
+  "version": "0.42.0",
   "type": "module",
   "license": "MIT",
   "repository": {
@@ -27,8 +27,8 @@
     "typecheck": "tsc --noEmit"
   },
   "dependencies": {
-    "@mercury-fw/channel-types": "0.40.0",
-    "@mercury-fw/plugin-types": "0.40.0"
+    "@mercury-fw/channel-types": "0.42.0",
+    "@mercury-fw/plugin-types": "0.42.0"
   },
   "devDependencies": {
     "@mercury-fw/typescript-config": "*",