Clarify package usage #79
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"?
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)