[Testing] Allow a test case to resolve package versions from a standalone composer.json - #8264
Merged
Merged
Conversation
…lone composer.json A rule that implements ComposerPackageConstraintInterface is filtered out unless the bonded package is installed, which includes its own test run. Extensions cannot always add the package to require-dev, so there was no way to test such a rule. AbstractRectorTestCase::provideComposerJsonFilePath() now points at a standalone "composer.json"; its "require" and "require-dev" constraints become the resolved versions, using the lowest version each one allows.
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.
A rule that implements
ComposerPackageConstraintInterfaceis filtered out unless the bonded package is installed —RectorNodeTraverser::prepareNodeVisitors()appliesComposerPackageConstraintFilterunconditionally, so this hits the rule's own test run too. Every fixture then reports no change and the test fails.That leaves an extension unable to test a rule bonded to a package it cannot add to
require-dev. Concretely, inrector-symfonyRedirectToRouteRectorbonds tosymfony/framework-bundle, which does not resolve against that repo's dev constraints at any major.A test case can now name a standalone
composer.jsonto read the versions from:The
requireandrequire-devconstraints become the resolved versions, each one taking the lowest version it allows —^2.6resolves to2.6.0.0. No vendor directory is read in this mode. An open constraint such as*has no lowest version and stays unresolved, same as a package that is not listed at all.Notes
InstalledPackageResolvergets an optional second constructor argument. Default behaviour is untouched: without it, versions still come fromvendor/composer/installed.jsonwith thecomposer.jsonconstraints applied on top.matchConstraintVersion()intoresolveConstraintLowestVersion()and shared by both modes.changeComposerJsonFilePath()exists becauseComposerPackageConstraintFilterkeeps the first resolver it is handed for the whole process. The test case binds the resolver as a singleton once, then re-points it per test case, so a customcomposer.jsoncannot leak into the next one. Re-binding the container entry instead would leave the filter holding a stale instance.Verified against
rector-symfony: with the rule bonded and this branch in place, its suite is green at 584 tests, including the 7RedirectToRouteRectorcases that fail without it.tests/Composer/InstalledPackageResolverTestcovers the new mode and the re-point. The 32 failures in the full suite are present onmainas well and are unrelated.