fix(ci): link monorepo root in laravel e2e so siblings resolve from working tree#8363
Merged
Merged
Conversation
…orking tree `composer global link ../src/Laravel` pointed pmu at the laravel subdir, so only api-platform/laravel got a path repo. The sibling packages (metadata, state, ...) fell back to packagist, where pmu's `@dev` constraint rewrite plus `prefer-stable` selected the top stable release (v4.3.15) — predating SortFilterInterface and crashing OrderFilter at runtime. Linking the monorepo root registers path repos for every split package; path repos win over packagist even under prefer-stable, so all api-platform/* resolve from the working tree while the Laravel ecosystem stays on stable.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
The
Laravel E2E installationjob fails on the 5.0 line with:The install resolves
api-platform/metadata(and other siblings) to the stale stablev4.3.15, which predatesSortFilterInterface.Root cause
The install step ran
composer global link ../src/Laravel, pointing pmu at the laravel subdir. pmu discovers monorepo packages from the directory it's given, so it found onlyapi-platform/laraveland registered a path repo for it alone.The sibling packages had no path repo, so they resolved from packagist. pmu's
linkrewrites inter-package constraints to@dev, and@dev+prefer-stablemakes composer pick the highest stable version —v4.3.15— which lacksSortFilterInterface.api-platform/laravelitself came from the working tree (the failing log shows5.0.x-dev 369bb2c, composer's path-repo reference), which is why the runtime crash hit the working-treeOrderFilteragainst 4.3.15 metadata.Fix
Link the monorepo root instead. pmu then registers path repos for every split package, and path repositories win over packagist even under
prefer-stable, so allapi-platform/*resolve from the working tree while the Laravel ecosystem stays on stable releases.Verification
Reproduced both the failure and the fix locally (composer dry-run) against an untagged checkout (PR-like), confirming source resolution:
5.0.x-dev(working tree)dev-main(working tree)v4.3.15(packagist)dev-main(working tree)v4.3.15(packagist)dev-main(working tree)Targets
4.3to propagate up to4.4andmain. pmu needs no change — the job linked the wrong directory.