Validate composer files.

[danepowell]

An easy and common mistake is to add a module as a composer.json dependency and forget to run composer update to generate a new composer.lock. This causes a lot of confusion when the module mysteriously doesn't get deployed.

This validates that composer.lock is up to date with composer.json (among other things).

[danepowell]

Hmm... doesn't seem that the failing tests are directly related to this PR.

[danepowell]

Maybe this should be part of the validation Phing tasks, instead of a separate Travis step.

[grasmash]

@danepowell If it's a phing task, when should it be executed? During the build of the docroot, of a deployment artifact, or when tests are run? Maybe a simple warning would suffice?

[danepowell]

I'd like composer validate to run as an automated test, as part of validate:all. The current solution was just an easier stopgap.

Composer already issues a warning if composer.json and composer.lock are out of sync, the problem is that people don't heed it. A failing test seems like necessary motivation.

[danepowell]

This should be ready to merge, the failing test is unrelated

[grasmash]

Rerunning tests.

[grasmash]

Looks like the failed tests may be related to composer validation:

     [exec] ./composer.json is valid for simple usage with composer but has
     [exec] strict errors that make it unable to be published as a package:
     [exec] See https://getcomposer.org/doc/04-schema.md for details on the schema
     [exec] description : The property description is required
     [exec] The package "phing/phing" is pointing to a commit-ref, this is bad practice and can cause unforeseen issues.
     [exec] require.roave/security-advisories : unbound version constraints (dev-master) should be avoided
     [exec] require.drupal-composer/drupal-security-advisories : exact version constraints (8.0.x-dev) should be avoided if the package follows semantic versioning

[danepowell]

As they should, since it turns out our composer.json is invalid. I will fix.