Currently the composer task gets triggered/run only when composer.json changes.
In many cases, only the composer.lock gets changed (of course, if it is committed/versioned in the project) and the composer task should run, otherwise we can end up with an invalid composer.lock hash (for example).
For example: if we merge/rebase a branch and have composer.lock conflicts, and the rebase doesn't contain any change to composer.json, and forget to run composer update --lock to refresh the hash after fixing conflicts, then we end up with an invalid lock hash.
Steps to reproduce:
On a project with the composer.lock committed/versioned, and the composer task enabled.
Hack (change manually) the composer.lock hash.
Commit, and notice that the grumphp composer task doesn't run.
The composer lock is now invalid, grumphp could prevent that.
Proposed resolution:
Add the composer.lock to the detection.
Possibly add a setting to enable/disable this, in order to keep the current behavior?
But would that have any applications/added value?
Currently the composer task gets triggered/run only when
composer.jsonchanges. In many cases, only thecomposer.lockgets changed (of course, if it is committed/versioned in the project) and the composer task should run, otherwise we can end up with an invalid composer.lock hash (for example).For example: if we merge/rebase a branch and have
composer.lockconflicts, and the rebase doesn't contain any change tocomposer.json, and forget to runcomposer update --lockto refresh the hash after fixing conflicts, then we end up with an invalid lock hash.Steps to reproduce: On a project with the
composer.lockcommitted/versioned, and the composer task enabled.Proposed resolution: Add the composer.lock to the detection.
Possibly add a setting to enable/disable this, in order to keep the current behavior? But would that have any applications/added value?