Bring in Packager and make console commands extendable#197
Conversation
…e application container
|
This pull request will be closed and archived in 3 days, as there has been no activity in the last 60 days. |
|
This pull request will be closed and archived in 3 days, as there has been no activity in the last 60 days. |
|
This pull request will be closed and archived in 3 days, as there has been no activity in the last 60 days. |
|
This pull request will be closed and archived in 3 days, as there has been no activity in the last 60 days. |
|
Important Review skippedDraft detected. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Companion to wintercms/winter#1259 (UpdateManager refactor). That refactor drives module/plugin/theme install and update operations through Composer instead of the legacy marketplace zip downloads, and streams console command output to the backend UI. This PR adds the Storm-side primitives required for that work:
winter/packager(^0.4.3) and add aWinter\Storm\Packager\Composerhelper that proxies to a sharedWinter\Packager\Composerinstance bound tobase_path(), plus higher-level helpers used by the new UpdateManager (getWinterPackages(),getAvailableUpdates(),getPackageInfoByExtension(),getWinterPackagesWithVersion(), etc.) for identifying Winter packages and their available updates from Composer metadata (vendor/composer/installed.json).Winter\Storm\Foundation\Extension\WinterExtensioninterface — a common contract (path / version / identifier / composer package info) for everything installable on top of Winter (modules, plugins, themes) so the UpdateManager and the extension managers in winter#1259 can treat them uniformly.ModuleServiceProviderimplements it here via the newHasComposerPackagetrait; the plugin & theme implementations live in winter#1259.Winter\Storm\Console\Commandnow usesExtendableTrait+Emitter, and overridesrun()to fire acommand.beforeRunevent once output is initialized. This allows external code (e.g. the web-based updater) to intercept a command's output/lifecycle, such as streamingwinter:updateoutput to the browser. The override replicates Laravel 9'sIlluminate\Console\Command::run()and invokes the grandparentSymfony\Component\Console\Command::run()directly, with a scoped Termwind renderer swap so nested/captured command output renders to the correct output stream.Merge considerations:
allow-plugins.php-http/discovery: falseconfig entry is needed becausewinter/packagercurrently depends onphp-http/discovery(which satisfies itspsr/http-client-implementationrequirement at resolution time). Downstream projects will face the Composer plugin allow-prompt on update unless packager drops this dependency first (see review discussion).winter/packagershould receive a stable v1.0 release when this is merged.winter/packageralso bringscomposer/composerinto the production dependency tree of every Winter install.