@mercury-fw/kit 0.32.0 → 0.34.0

package/CHANGELOG.md

@@ -1,5 +1,29 @@
 # @mercury-fw/kit
 
+## 0.34.0
+
+### Patch Changes
+
+- Updated dependencies [8bed46b]
+  - @mercury-fw/channel-types@0.34.0
+  - @mercury-fw/plugin-types@0.34.0
+
+## 0.33.0
+
+### Minor Changes
+
+- a493d9b: - A plugin whose CLI keeps its login in a folder declares it in its `package.json` (`mercury.cliCredentials`): `{ folder }` under `~/.config`, the default, or `{ path }` anywhere else under the home. Any plugin's CLI gets the login mechanism, not only the first-party ones.
+  - The core unpacks each declared login from its env variable onto the credentials volume (`~/.config`) at startup, only when the folder isn't there yet, for the service and the REPL alike; a folder declared elsewhere in the home lives on the volume under `~/.config/mercury-home`, linked from its usual place. It warns about a declared folder with neither the folder nor the variable.
+  - `mfw credentials set|reset <plugin>` names the plugin by its package or its CLI's folder (`@mercury-fw/plugin-jira` or `jira-cli`), read from the app's installed plugins; the short name (`jira`) is no longer accepted, and reset asks for the folder's name.
+  - `mfw create` no longer writes `docker-entrypoint.sh` or the credentials variables in the env example, and always mounts the `cli-credentials` volume; an existing app's entrypoint keeps working alongside.
+  - The generated README explains how a plugin's CLI gets its login without listing plugins.
+  - jira, bitbucket and atlassian-admin declare their CLI's login folder; their READMEs point to `mfw credentials set`.
+
+### Patch Changes
+
+- @mercury-fw/plugin-types@0.33.0
+- @mercury-fw/channel-types@0.33.0
+
 ## 0.32.0
 
 ### Patch Changes

package/README.md

@@ -2,6 +2,20 @@
 
 What a [Mercury](https://github.com/lucabro81/mercury-fw) plugin author imports: the contract a tool plugin implements (`Plugin`, `PLUGIN_API_VERSION` and the types around them) and the one a channel implements (`ChannelPlugin`, `CHANNEL_API_VERSION`), in one place. It carries no runtime, so a plugin that depends on it doesn't pull the framework in.
 
+A plugin whose CLI keeps its login in a folder under the home, reading it from there at runtime, declares that folder in its `package.json`, by default under `~/.config`:
+
+```json
+{
+  "mercury": {
+    "cliCredentials": { "folder": "my-cli" }
+  }
+}
+```
+
+or anywhere else under the home, with `{ "path": ".my-cli" }` instead (relative to the home, inside it).
+
+An app then carries the login into its container with `mfw credentials set <plugin>`, and unpacks it at startup 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 proper workflow for writing plugins, with an SDK on top of these contracts, is planned ([#27](https://github.com/lucabro81/mercury-fw/issues/27)).
 
 MIT

package/package.json

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