feat(pluginkit): register compiled plugins one by one from a generated list

.codescene/code-health-rules.json

@@ -0,0 +1,11 @@
+{
+  "rule_sets": [
+    {
+      "matching_content_path": "**/*_test.go",
+      "rules": [
+        { "name": "String Heavy Function Arguments", "weight": 0.0 },
+        { "name": "Primitive Obsession", "weight": 0.0 }
+      ]
+    }
+  ]
+}

pluginkit/CHANGELOG.md

@@ -3,6 +3,12 @@
 Releases of this module are tagged `pluginkit/vX.Y.Z`. Releases up to
 0.5.1 were tagged `vX.Y.Z` in `github.com/gopherium/pluginkit`.
 
+## Unreleased
+
+- `RegisterEach` calls each `Registration` with the dependencies `depsFor` builds for its id, each inside its own recover, goes on past an error or a panic, and answers a `RegisterOutcome` naming each failure at the new `StepRegister`.
+- `wire.Config` gains an optional `RegistrationList`, which makes each generated Go file hold a list of every backend plugin's id and `Register`, `pluginRegistrations` in the main file and `Registrations` in the registry, in place of `registerPlugins` and `All`.
+- The host's own recovers name a panic whose value panics again while it is printed by its type, where the process used to crash.
+
 ## 0.11.0 - 2026-11-07
 
 - `wire.Manifest` reads `menu` as `[]MenuEntry`, and `screens` and `screen_capabilities`, which no longer sit in `Extra`, a breaking change.

pluginkit/features/features_test.go

@@ -41,3 +41,7 @@ func TestHooks(t *testing.T) {
 func TestScreens(t *testing.T) {
 	runFeature(t, "screens.feature", initializeScreens(t))
 }
+
+func TestRegistration(t *testing.T) {
+	runFeature(t, "registration.feature", initializeRegistration(t))
+}

pluginkit/features/registration.feature

@@ -0,0 +1,92 @@
+Feature: Registering compiled plugins one by one
+  A downstream application can ask the wiring generator for a list of
+  every backend plugin's id and Register function, in wiring order, in
+  place of one function that registers them all. The application keeps
+  the plugins it wants on, builds each one's dependencies from its id,
+  and registers them one by one. A plugin whose Register fails or panics
+  is reported by its id, and the plugins after it still register.
+
+  Scenario: The registration list names each backend plugin in wiring order
+    Given the plugin "events" has a backend
+    And the plugin "gallery" has a backend
+    And the plugin "pretty" has only the frontend "@example/plugin-pretty"
+    And the application asks for a registration list
+    When the plugins are wired
+    Then the registration list names "events" and "gallery", in that order
+    And the Go wiring holds no registerPlugins function
+
+  Scenario: The registry holds an exported registration list in place of All
+    Given the plugin "events" has a backend
+    And the application asks for a registration list and a registry
+    When the plugins are wired
+    Then the registry's Registrations names "events"
+    And the registry holds no All function
+
+  Scenario: Without a registration list the Go wiring keeps registerPlugins
+    Given the plugin "events" has a backend
+    When the plugins are wired
+    Then the Go wiring holds the registerPlugins function
+    And the Go wiring holds no registration list
+
+  Scenario: Only the plugins the application passes are registered
+    Given the compiled plugins "events", "feed" and "gallery"
+    And the application leaves "gallery" out
+    When the application registers each plugin
+    Then "events" and "feed" are registered, in that order
+    And the Register of "gallery" never ran
+
+  Scenario: Each plugin receives the dependencies built for its own id
+    Given the compiled plugins "events" and "feed"
+    When the application registers each plugin
+    Then the Register of "events" received the dependencies built for "events"
+    And the Register of "feed" received the dependencies built for "feed"
+    And dependencies were built for "events" and "feed", in that order, once each
+
+  Scenario: A plugin whose Register panics fails alone
+    Given the compiled plugins "events", "feed" and "gallery"
+    And the Register of "feed" panics with "boom"
+    When the application registers each plugin
+    Then "events" and "gallery" are registered, in that order
+    And "feed" failed at the step "register" with: pluginkit: feed register panicked: boom
+    And the failure of "feed" is marked as a panic
+
+  Scenario: A plugin whose Register answers an error fails alone
+    Given the compiled plugins "events", "feed" and "gallery"
+    And the Register of "feed" answers the error "the title is too long"
+    When the application registers each plugin
+    Then "events" and "gallery" are registered, in that order
+    And "feed" failed at the step "register" with: pluginkit: feed register: the title is too long
+    And the failure of "feed" is not marked as a panic
+
+  Scenario: An error that holds the text of a panic is not marked as a panic
+    Given the compiled plugins "events" and "feed"
+    And the Register of "feed" answers the error "pluginkit: feed register panicked: boom"
+    When the application registers each plugin
+    Then "feed" failed at the step "register" with: pluginkit: feed register: pluginkit: feed register panicked: boom
+    And the failure of "feed" is not marked as a panic
+
+  Scenario: Registering no plugin answers an empty outcome
+    Given no compiled plugin
+    When the application registers each plugin
+    Then no plugin is registered and none failed
+
+  Scenario: A panic while the application builds dependencies is not recovered
+    Given the compiled plugins "events" and "feed"
+    And building the dependencies of "feed" panics with "no settings for feed"
+    When the application registers each plugin
+    Then the registering panics with "no settings for feed"
+    And the Register of "feed" never ran
+
+  Scenario Outline: The generated list builds and registers each plugin
+    Given an SDK whose Plugin is <sdk plugin>
+    And the plugin "events" has a backend whose Register answers a plugin
+    And the plugin "feed" has a backend whose Register answers the error "no database"
+    And the application asks for a registration list
+    When the plugins are wired, built and registered one by one
+    Then "events" is registered
+    And "feed" failed at the step "register" with: pluginkit: feed register: no database
+
+    Examples:
+      | sdk plugin                       |
+      | an alias of the pluginkit Plugin |
+      | an interface of its own          |