fix: detect local path-repository plugins during project upgrade - #1475
Conversation
|
Caution Review failedThe pull request is closed. ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Team Run ID: 📒 Files selected for processing (11)
📝 WalkthroughWalkthroughChangesLocal Composer Plugin Upgrade Support
Estimated code review effort: 4 (Complex) | ~45 minutes Sequence Diagram(s)sequenceDiagram
participant Project
participant discoverExtensions
participant classifyExtension
participant RewriteComposerJSON
participant extensionDetail
Project->>discoverExtensions: Read composer.lock and installed extensions
discoverExtensions->>classifyExtension: Provide PathInstalled and Require
classifyExtension-->>extensionDetail: Return ExtOK, ExtBlocked, or ExtReview
Project->>RewriteComposerJSON: Rewrite upgrade constraints
RewriteComposerJSON-->>Project: Preserve path-installed constraints
✨ Finishing Touches📝 Generate docstrings
🧪 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 |
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #1475 +/- ##
==========================================
+ Coverage 62.61% 62.72% +0.11%
==========================================
Files 436 436
Lines 29415 29500 +85
==========================================
+ Hits 18419 18505 +86
+ Misses 10996 10995 -1
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
46ed75b to
30b2732
Compare
30b2732 to
85a48ab
Compare
85a48ab to
d5575bf
Compare
d5575bf to
65a7d19
Compare
65a7d19 to
08f0aa0
Compare
project upgrade treated Composer path-repository plugins (custom/static-plugins) as missing Packagist packages, so compatibility showed "none" and blocked. autofix composer-plugins also re-scanned those already-managed plugins after resolving vendor symlinks back into custom/. Classify path and other unpublished packages from the installed composer.json require, skip already-required plugins during autofix, and keep path packages pinned instead of rewriting them to "*". Co-authored-by: xai <xai@shyim.de>
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
08f0aa0 to
2330f52
Compare
Fixes #1463
What changed?
shopware-cli project upgradetreated Composer path-repository plugins (typically undercustom/static-plugins) as missing Packagist packages, so compatibility showed1.0.0 -> noneand blocked the upgrade.project autofix composer-pluginsalso re-scanned those already-managed plugins after resolving vendor symlinks back intocustom/, then failed oncomposer require.composer.json/ lockrequire(usuallyshopware/core). A constraint that allows the target is OK; one that does not still blocks, with the actual constraint in the message.composer.lockorcomposer.jsonrequire.*.Why?
Plugin developers keep local plugins in
custom/static-pluginsand manage them with Composer path repositories. The upgrade wizard should check those plugins' own Shopware constraints instead of looking for a published release that does not exist.How was this tested?
Unit tests covering the reported layout (
custom/static-plugins/*path repo, lockdist.type: path, vendor symlink):~6.7.0→ExtOK, available1.0.0~6.6.0→ExtBlockedwith the constraint in the detailshopware/coreconstraint instead of “ask the vendor”Related issue or discussion
#1463
Summary by CodeRabbit
Bug Fixes
User Experience