Conversation
|
|
||
| You may manually trigger a version check only by using the `--dry-run` flag on an update. | ||
|
|
||
| This requires Composer version 2 however, due to a wont-fix issue in deprecated Composer 1.x. |
There was a problem hiding this comment.
The tool also works with composer:^1 - there are limitations with it, but it has worked since forever with it?
There was a problem hiding this comment.
See linked issue #66, the manual check with existing composer.lock does not work with Composer 1.x. It needs Composer 2.
The other commands (compose require and composer update without dry-run) work fine with Composer 1. But this section is about the dry-run.
PS: The diff is a hard to to read → this is what the rendered version of the text change looks like:
https://github.com/pixelbrackets/SecurityAdvisories/blob/20210813_add-composer-version-requirement/README.md
| The checks are only executed when adding a new dependency via `composer require` or when running `composer update`: | ||
| deploying an application with a valid `composer.lock` and via `composer install` won't trigger any security versions | ||
| checking. | ||
| ### Manual checks |
There was a problem hiding this comment.
Would rather say that these are for continuous integration
There was a problem hiding this comment.
What do you mean with "these". Replace the headline "Manual checks" with "Continuous integration"?
2 participants
Split installation and usage description.
Extend description how the package works and when it runs.
Explain need for Composer 2 in manual version checks (see #66)