Use composer test for php-related validations

[jhedstrom]

Over in #312 there is a partial fix for the

Warning: spawn E2BIG Use --force to continue.

error that occurs when too many files exist in the project to be passed in as arguments to phpcs. That fix works. However, there is now a related error where that occurs for the phplint portion of grunt validate:phpcs. There isn't a workaround for that that I'm aware of.

Given that, I would propose we switch to using composer test for php-related validations. This would look something like the following in the composer.json file:

    "scripts": {
        "test": [
            "composer validate --no-interaction",
            "parallel-lint src tests",
            "phpcs --encoding=utf-8 --standard=phpcs.xml --report-checkstyle=reports/checkstyle-phpcs.xml --report-full --extensions=php src/* tests/*"
        ]
    }

this test script could eventually be extended to include the other components of grunt test, such as phpunit and behat.

[grayside]

I've had composer validate on my mind, and parallel-lint looks awesome.

The problem here is it moves control over validation outside grunt configuration & execution. Can we parameterize the configuration used there to bridge in things done in GDT, or do you see this as a "select PHP-native mode" as a project configuration?

Example use case: #310

[jhedstrom]

I'm not sure what could be parameterized...we could potentially make the 'test' part of composer test configurable...

Another benefit, when running natively, the progress bars are pretty sweet:

[grayside]

We can wrap this in a compatibility mode config, but here are the parts to pay attention to:

1. grunt watch (I suspect broken anyway)
2. grunt git-setup (currently installs grunt validate:staged as a pre-commit script)
3. grunt validate with a couple different "reporting" modes, such as summary calls phplint, phpcs, and eslint.
4. grunt analyze which runs phpcs, phpmd, and eslint but produces a report as a file so it can be used for displaying charts or tracking trends.

The thing these all have in common is that grunt wants to invoke these commands. It can do them via composer perhaps instead of using the grunt-plugin, which seems pretty good to me. We will probably need to have a few different composer test variations to match current behavior. composer test, composer test-summary, composer test-save-results and the like.

[jhedstrom]

Coming back to this after a while, I'm not exactly sure what the best path forward here is. Having too many grunt to composer command mappings seems a bit unmaintainable, unless we can achieve it solely with grunt config...