Normalize composer.json file#226
Normalize composer.json file#226ghostwriter wants to merge 4 commits intoPHPCSStandards:stablePHPCSStandards/PHPCSDevTools:stablefrom ghostwriter:oss/composer/normalize-composer-json-fileghostwriter/PHPCSDevTools:oss/composer/normalize-composer-json-fileCopy head branch name to clipboard
Conversation
|
@ghostwriter Would you mind rebasing this PR on Sorry about that, but doing a file rewrite like this only in |
89e2008 to
3472734
Compare
Reformat and normalize `composer.json`. Add `@phpunit` and `@xdebug` scripts (setting `XDEBUG_MODE=coverage`) and update test scripts to enable coverage in future PRs. Signed-off-by: Nathanael Esayeas <nathanael.esayeas@protonmail.com>
3472734 to
53ca0bb
Compare
jrfnl
left a comment
There was a problem hiding this comment.
@ghostwriter Thanks for this PR.
I've left a few small notes inline, but mostly looking good.
| "autoload": { | ||
| "psr-4": { | ||
| "PHPCSDevTools\\Scripts\\": "Scripts/" | ||
| } | ||
| }, |
There was a problem hiding this comment.
Hmm... I wonder why nobody complained about that being missing before. Then again, I can see it's working in PHPCSExtra without this, so 🤷🏻♀️ .
In develop, the "feature complete" feature has been refactored and includes the autoload section, as well as a custom autoload file: devtools-autoload.php
I currently can't think of a good reason not to add it for stable too (though there must have been a reason I didn't before 😉 ).
There was a problem hiding this comment.
Hmm... I wonder why nobody complained about that being missing before. Then again, I can see it's working in PHPCSExtra without this, so 🤷🏻♀️ .
Because you were manually requiring the class files in bin/phpcs-check-feature-completeness.
PHPCSDevTools/bin/phpcs-check-feature-completeness
Lines 38 to 40 in cdeaac3
In
develop, the "feature complete" feature has been refactored and includes theautoloadsection, as well as a custom autoload file: devtools-autoload.phpI currently can't think of a good reason not to add it for
stabletoo (though there must have been a reason I didn't before 😉 ).
I will add the devtools-autoload.php file and let composer autoload it.
"autoload": {
"psr-4": {
"PHPCSDevTools\\Scripts\\": "Scripts/"
},
"files": [
"devtools-autoload.php"
]
},
There was a problem hiding this comment.
Hmm... I wonder why nobody complained about that being missing before. Then again, I can see it's working in PHPCSExtra without this, so 🤷🏻♀️ .
Because you were manually requiring the class files in
bin/phpcs-check-feature-completeness.
But that was only supposed to happen if there was no Composer autoload.php.
I currently can't think of a good reason not to add it for
stabletoo (though there must have been a reason I didn't before 😉 ).I will add the
devtools-autoload.phpfile and let composer autoload it.
No, please don't. I'm okay with adding the autoload section. It shouldn't do any harm. Any further autoloading changes are for the develop branch. I don't want us to miss anything and break stable.
There was a problem hiding this comment.
Hmm... I wonder why nobody complained about that being missing before. Then again, I can see it's working in PHPCSExtra without this, so 🤷🏻♀️ .
Because you were manually requiring the class files in
bin/phpcs-check-feature-completeness.But that was only supposed to happen if there was no Composer
autoload.php.
yes, which is always the case here.
The is_file(__DIR__ . '/../autoload.php') check always returns false.
PHPCSDevTools/bin/phpcs-check-feature-completeness
Lines 33 to 42 in cdeaac3
This:
__DIR__ . '/../autoload.php'
resolves to:
/Volumes/workspace/OSS/PHPCSStandards/PHPCSDevTools/autoload.php
not:
/Volumes/workspace/OSS/PHPCSStandards/PHPCSDevTools/vendor/autoload.php
Globally: ~/.composer/vendor/autoload.php
Current Project: ./../vendor/autoload.php
Relative path to another project: ./../../vendor/autoload.php
When Composer autoloads bins, it sets $_composer_autoload_path.
I usually fall back to:
$_composer_autoload_path ?? implode(DIRECTORY_SEPARATOR, [dirname(__DIR__), 'vendor', 'autoload.php'])
it works cross-platform.
There was a problem hiding this comment.
| "@php ./vendor/phpunit/phpunit/phpunit" | ||
| "@phpunit" | ||
| ], | ||
| "test-sniff": [ | ||
| "@php ./vendor/phpunit/phpunit/phpunit --testsuite DebugSniff" | ||
| "@phpunit --testsuite DebugSniff" | ||
| ], | ||
| "test-tools": [ | ||
| "@php ./vendor/phpunit/phpunit/phpunit --testsuite DevTools" | ||
| "@phpunit --testsuite DevTools" | ||
| ], | ||
| "test-lte9": [ | ||
| "@php ./vendor/phpunit/phpunit/phpunit -c phpunitlte9.xml.dist" | ||
| "@phpunit -c phpunitlte9.xml.dist" | ||
| ], | ||
| "test-sniff-lte9": [ | ||
| "@php ./vendor/phpunit/phpunit/phpunit -c phpunitlte9.xml.dist --testsuite DebugSniff" | ||
| "@phpunit -c phpunitlte9.xml.dist --testsuite DebugSniff" | ||
| ], | ||
| "test-tools-lte9": [ | ||
| "@php ./vendor/phpunit/phpunit/phpunit -c phpunitlte9.xml.dist --testsuite DevTools" | ||
| "@phpunit -c phpunitlte9.xml.dist --testsuite DevTools" | ||
| ], | ||
| "check-complete": [ | ||
| "@php ./bin/phpcs-check-feature-completeness ./PHPCSDebug" | ||
| ], | ||
| "phpunit": [ | ||
| "@xdebug", | ||
| "@php ./vendor/phpunit/phpunit/phpunit" | ||
| ], | ||
| "xdebug": [ | ||
| "@putenv XDEBUG_MODE=coverage" |
There was a problem hiding this comment.
I'm not sure why you are making this change at this time ?
As things are, there is no code coverage set up in the PHPUnit config files, so code coverage isn't (and shouldn't be) run at this time. It feels like this doesn't belong in this PR ?
For when code coverage does get set up and enabled in CI:
I tend to default to the test* scripts being the ones running without code-coverage (and with the --no-coverage flag) and having separate coverage* scripts (with the same suffixes) for running the same commands with code coverage.
There was a problem hiding this comment.
For the record - I did test the script changes on Windows and see no blockers for adding this change at a later point when it becomes relevant.
There was a problem hiding this comment.
I'm not sure why you are making this change at this time ?
As things are, there is no code coverage set up in the PHPUnit config files, so code coverage isn't (and shouldn't be) run at this time. It feels like this doesn't belong in this PR ?
Agreed, this doesn't belong in this PR.
For when code coverage does get set up and enabled in CI: I tend to default to the
test*scripts being the ones running without code-coverage (and with the--no-coverageflag) and having separatecoverage*scripts (with the same suffixes) for running the same commands with code coverage.
I'll make a note of this, thanks.
Signed-off-by: Nathanael Esayeas <nathanael.esayeas@protonmail.com>
Signed-off-by: Nathanael Esayeas <nathanael.esayeas@protonmail.com> Co-Authored-By: Juliette <663378+jrfnl@users.noreply.github.com>
This reverts commit 3a0ff91.
Reformat and normalize
composer.json.Add
@phpunitand@xdebugcomposer scripts (settingXDEBUG_MODE=coverage) and update test scripts to enable coverage in future PRs.