From 78c23c7105914b74ae91c71496265d3b03d7e285 Mon Sep 17 00:00:00 2001 From: nsfisis Date: Sun, 9 Aug 2026 19:10:27 +0900 Subject: feat(plugin): let a Rust-implemented plugin cross into the worker PluginManager::getPluginCapability hands the plugin itself to the capability constructor. Only a PHP-implemented plugin had an entity the child could receive, so a Rust-implemented one bailed out; it now crosses as a handle to an R-table entity behind Shirabe\RustPluginStub, or its Capable flavour, since `$plugin instanceof Capable` is what decides whether Composer asks a plugin for capabilities at all. This is what the two capability tests of PluginInstallerTest were waiting on: the mocked Capable plugin is Rust-side, and one of them asserts the identity of the plugin read back out of $capability->args. --- crates/shirabe/src/plugin/capability/capability.rs | 6 ++++++ 1 file changed, 6 insertions(+) (limited to 'crates/shirabe/src/plugin/capability') diff --git a/crates/shirabe/src/plugin/capability/capability.rs b/crates/shirabe/src/plugin/capability/capability.rs index aa70ffa0..bb634b9f 100644 --- a/crates/shirabe/src/plugin/capability/capability.rs +++ b/crates/shirabe/src/plugin/capability/capability.rs @@ -11,4 +11,10 @@ pub trait Capability { fn as_command_provider(&self) -> Option<&dyn CommandProvider> { None } + + /// For testing only: recovers the PHP-backed proxy so tests can read capability properties + /// the way PHPUnit asserts `$capability->args`. + fn __as_php_capability_proxy(&self) -> Option<&crate::plugin::PhpCapabilityProxy> { + None + } } -- cgit v1.3.1-4-g156e