| Age | Commit message (Collapse) | Author |
|---|
|
plugin_installer_test.rs carried its own copy of php_runtime_available,
lock_php_worker and load_composer_php_runtime, and the other ten files
in the binary imported them from there. The bodies matched
tests/common/php_worker.rs, so include that instead.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
|
The worker's autoloader fell through to the real Composer source for every
Rust-owned FQCN without a proxy stub, so plugin code doing `new Filesystem()`
or subclassing `LibraryInstaller` silently ran on a second instance the Rust
side never sees. An unimplemented part of the plugin API has to fail with an
explicit error naming it, not quietly work on a disconnected copy.
The stub generator now emits a guard class for each of those FQCNs: the real
declaration, hierarchy and constants, with every constructor and method
raising an explicit error. References satisfied by the declaration alone
(`instanceof`, `X::class`, `Link::TYPE_REQUIRE`) keep working. Two FQCNs stay
resolvable to the real class, each listed with the worker-side mechanism that
makes a natively constructed instance correct.
The error had nowhere to go: `Installer::run` dropped the `Result` of both
`dispatch_script` calls, so an exception from a listener ended in exit 0.
Both propagate now, the way the exception does upstream.
Three real-plugin E2E comparisons stop at a guard and are ignored, each
naming the class it needs.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
|
A single install leaves the installer contract half tested: it never reaches
`update`, never runs over an already-installed tree, and never reaches the
plugin's own `uninstall()` override — the one chaining onto the promise
`LibraryInstaller::uninstall` returns. Nor does it touch the configuration
surface real projects use, `installer-paths` and `installer-name`, which the
plugin reads back through the package proxy.
All three now compare command output as well as the resulting tree against
upstream Composer. Progress bar frames are dropped from that comparison:
Shirabe renders them differently for every install, including projects with
no plugin at all, so they say nothing about the plugin under test.
With those covered the plugin joins the verified list in the README.
|
|
The fixture project pins composer/installers 2.3.0 and requires two packages
of framework-specific types, so the plugin's LibraryInstaller subclass decides
where they land. Upstream Composer and Shirabe install the same project and
the whole resulting tree is compared.
The plugin tarball is fetched by `fixtures/e2e-installers/fetch` into a
git-ignored directory and pinned by a digest over the extracted files, so the
third-party source never enters this repository and the test skips itself
while the directory is absent. The tree is staged and only moved into place
once verified, so an unverified tree is never observable under the name the
test looks for.
|
