Add composer fields to silence PHPStan

[jeffwidman]

Addresses the following warnings:

16.51 > phpstan analyse
16.82 Note: Using configuration file /opt/composer/v1/phpstan.neon.
18.22  0/6 [░░░░░░░░░░░░░░░░░░░░░░░░░░░░]   0% 6/6 [▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓] 100%
18.31
18.31
18.31  [OK] No errors
18.31
18.73 ./composer.json is valid for simple usage with Composer but has
18.73 strict errors that make it unable to be published as a package
18.73 See https://getcomposer.org/doc/04-schema.md for details on the schema
18.73 # General warnings
18.73 - No license specified, it is recommended to do so. For closed-source software you may use "proprietary" as license.
18.73 # Publish warnings
18.73 - name : The property name is required
18.73 - description : The property description is required

As noted, these are not strictly needed given that we aren't publishing packages / libraries, but it's always nice to silence warnings for less visual noise.

After editing the composer.json file, composer.lock was regenerated
using composer install && composer update --lock. I made sure to use
composer1 for the v1 helpers, and composer for the v2 helpers.

Fix #5695

[jeffwidman]

Complains that I need to regenerate the composer.lock file, but I can't find a way to do that w/o bumping a bunch of libs... when all we need is a single hash updated. 🤦

I'll open a separate PR to run composer update to pickup the other changes first.

[stefangr]

@jeffwidman use composer update --lock to only update the lockfile, but not the libraries.

See: https://getcomposer.org/doc/03-cli.md#update-u

[jeffwidman]

Thanks, I did try composer update --lock, but it still resulted in bumping the transitive dependencies which are only listed in the lockfile... what i want is to only regenerate the hash that composer uses to validate that composer.json and composer.lock are in-sync... w/o bumping any library versions at all, not even transitive ones.

[stefangr]

@jeffwidman
With a fresh checkout of this branch and a composer install to install the dependencies from the current composer.lock file, the result of a composer update --lock is as I expected.

v1/composer.lock

• Only the content-hash is changed

v2/composer.lock

• The content-hash is changed
• A support section is added to some of the dependencies (when run with the composer v2 executable)

In the vendor/composer directory composer keeps a file (installed.json) that contains the actual versions of the installed dependencies.
If you have updated dependencies in a different branch, than that is in the installed.json.
If you perform a composer install the installed.json file is updated to the situation from the composer.lock.

My guess is that you did not perform a composer install before executing the composer update --lock while the installed.json from the vendor directory was updated in one of the other composer related branches.

[jeffwidman]

My guess is that you did not perform a composer install before executing the composer update --lock while the installed.json from the vendor directory was updated in one of the other composer related branches.

Thanks @stefangr that was exactly it!

[jeffwidman]

I did notice this change also crept in with composer update --lock. But it should be fine given that we don't use any plugins, and even if we did I suspect we'd want to be on the v2 API given that this is composer v2.

[jeffwidman]

PHPStan will still complain about this, since it's not a SPDX identifier: https://github.com/dependabot/dependabot-core/actions/runs/3049309247/jobs/4915246993#step:6:175

I looked into submitting this license for inclusion into SPDX index, but after reading through spdx/license-list-XML#960 decided that wasn't worth pursuing further.

I could have used "proprietary", but decided to just ignore that warning for now.