Patch "validate --no-check-lock" #10723
Merged
Conversation
This file contains 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
ktomk
force-pushed
the
patch-validate-no-check-lock
branch
from
7e4a8b7
to
50c999b
Compare
ktomk
force-pushed
the
patch-validate-no-check-lock
branch
from
50c999b
to
9bfd059
Compare
ktomk
force-pushed
the
patch-validate-no-check-lock
branch
3 times, most recently
from
983d680
to
a8d3689
Compare
stof
reviewed
Apr 12, 2022
ktomk
force-pushed
the
patch-validate-no-check-lock
branch
from
a8d3689
to
59a541d
Compare
ktomk
force-pushed
the
patch-validate-no-check-lock
branch
3 times, most recently
from
49eb14b
to
dc84f03
Compare
if no lock-file is configured, turn lock file validation errors into
warnings (implicit --no-check-lock) unless those are explicitly promoted
via the new --check-lock option.
- `{"config": {"lock": false}}` is an implicit `--no-check-lock` for
composer validate.
- `--check-lock` overrides an (implicit or explicit) `--no-check-lock`,
always.
issue: composer#10715
ktomk
force-pushed
the
patch-validate-no-check-lock
branch
from
132d3a4
to
939c998
Compare
Seldaek
reviewed
Apr 13, 2022
| @@ -45,6 +45,7 @@ protected function configure() | |||
| ->setDescription('Validates a composer.json and composer.lock.') | |||
| ->setDefinition(array( | |||
| new InputOption('no-check-all', null, InputOption::VALUE_NONE, 'Do not validate requires for overly strict/loose constraints'), | |||
| new InputOption('check-lock', null, InputOption::VALUE_NONE, 'Check if lock file is up to date (even config.lock is false, overrides --no-check-lock)'), | |||
There was a problem hiding this comment.
I'd keep this simpler, or leave the flag out altogether as I don't really see the point if you disabled the lock file..
Suggested change
| new InputOption('check-lock', null, InputOption::VALUE_NONE, 'Check if lock file is up to date (even config.lock is false, overrides --no-check-lock)'), | |
| new InputOption('check-lock', null, InputOption::VALUE_NONE, 'Check if lock file is up to date (even when config.lock is false)'), |
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.
if no lock-file is configured, turn lock file validation errors into warnings (implicit --no-check-lock) unless those are explicitly promoted via the new
--check-lockoption.{"config": {"lock": false}}is an implicit--no-check-lockfor composer validate.--check-lockoverrides an (implicit or explicit)--no-check-lock, always.rationale is that if no composer.lock file is configured in composer.json, the validate command should not fatal over it but instead demote to warning as the suggestion given in the warning won't work unless composer.lock is configured again (and there is no error as the lock-file is ignored by composer).
the difference this makes is the one between an exit status of zero or non-zero, between success and failure.
that is, if (and as) composer validate is used in check scripts (e.g. CI, tests, hooks etc.), it won't stumble over old lock-file artifacts, whatever the reasons may be.
(originally reported and fix idea / context in #10715)