Repository navigation
Floor laravel/pint at the version whose output is committed - #4
Merged
Merged
Conversation
The prefer-lowest leg installs the declared floor, and Pint's floor was old enough to format differently from the version that produced the committed code. Measured on laranail/db-tools: `laravel/pint: ^1.18` resolves 1.18.0 under --prefer-lowest, and `laranail-pint --test` FAILS against it while passing on 1.30.x. laranail/chrono hit exactly this and went red on prefer-lowest while prefer-stable was green. So the floor moves to ^1.30 - the line whose output is what is actually in the repository. Verified rather than assumed: with this constraint --prefer-lowest installs 1.30.0, and laranail-pint passes against it on both db-tools (159 reformatted files) and console (210). Pint is require-dev, so this is invisible to consumers: it constrains nothing they install. It only stops the lowest leg testing a formatter that disagrees with the code it is checking. Deliberately NOT applied to rector: at its ^2.5.8 floor Rector resolves 2.5.8 and PASSES, because it reports what it *would* change and an older release carries fewer rules. Flooring it would be churn with no failure behind it.
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.
Floor laravel/pint at the version whose output is committed
The prefer-lowest leg installs the declared floor, and Pint's floor was old
enough to format differently from the version that produced the committed code.
Measured on laranail/db-tools:
laravel/pint: ^1.18resolves 1.18.0 under--prefer-lowest, and
laranail-pint --testFAILS against it while passing on1.30.x. laranail/chrono hit exactly this and went red on prefer-lowest while
prefer-stable was green.
So the floor moves to ^1.30 - the line whose output is what is actually in the
repository. Verified rather than assumed: with this constraint --prefer-lowest
installs 1.30.0, and laranail-pint passes against it on both db-tools (159
reformatted files) and console (210).
Pint is require-dev, so this is invisible to consumers: it constrains nothing
they install. It only stops the lowest leg testing a formatter that disagrees
with the code it is checking.
Deliberately NOT applied to rector: at its ^2.5.8 floor Rector resolves 2.5.8
and PASSES, because it reports what it would change and an older release
carries fewer rules. Flooring it would be churn with no failure behind it.