Action erroring out on with incorrect invalid composer.json report

[jrfnl]

Description

Okay, so this is a "fun" one 😕. If I make a simple --no-update change ahead of running the composer-install action, it will error out saying the composer.json file is invalid, while in actual fact the composer.json file is perfectly valid, but the (committed) lock file is out of date (which may be completely intentional).

Making a --no-update change ahead of running the composer-install action is a common way to ensure the caching done via composer-install is used optimally, while still being able to make select changes depending on the PHP version the workflow is being run on.

Steps to reproduce

1. On a repo with a committed composer.lock file
2. Run a composer .... --no-update command or other Composer command which won't run update, like composer config --unset platform.php
3. Try to run a composer update via the action and see it fail.
4. Run composer validate --strict: it will indicate the composer.json is valid, but the lock file is out of date.

   ./composer.json is valid but your composer.lock has some errors
   # Lock file errors
   - The lock file is not up to date with the latest changes in composer.json, it is recommended that you run `composer update` or `composer update <package name>`.
   

Example code to reproduce the issue: https://github.com/jrfnl/composer-install-action-bug

Action run showing the bug: https://github.com/jrfnl/composer-install-action-bug/actions/runs/1620893221

Expected behavior

That the composer-install action doesn't error out on the lock file being out of date as this may be wholly intentional, especially if a (selective) composer update is being run via the composer-install action.

Environment details

• version of this package: 2.0.2
• PHP version: not relevant
• OS: not relevant

[jrfnl]

FYI: I've got a fix lined up for this, as well as the test for it, I just can't get the test to be recognized by expect.

Unfortunately, I'm out of luck with the (otherwise very informative) CONTRIBUTING doc, as it presumes dev on a *nix based machine, while I'm on Windows, so autoexpect isn't available (the last Windows release for coreutils is 5.3.0).

How would you like me to proceed ?

[ramsey]

FYI: I've got a fix lined up for this, as well as the test for it, I just can't get the test to be recognized by expect.

Go ahead and push your fix and open the PR for it. I can help with the expect tests.

[jrfnl]

FYI: I've got a fix lined up for this, as well as the test for it, I just can't get the test to be recognized by expect.

Go ahead and push your fix and open the PR for it. I can help with the expect tests.

Pulled as draft in #213