Problem/Motivation
Recently, a new top-level directory composer was introduced. This directory holds sources for code that does not need to be packaged in the drupal/core subtree split, and therefore should not be in the core directory. However, only things in the core directory are being tested with phpcs, leading to a growing collection of coding violations in the composer location.
Proposed resolution
We should ensure that the composer directory is also sniffed for conformance with the Drupal coding standards. We could do this either by copying the phpcs configuration from the core directory, or by making a relative path from within the phpcs configuration file to the composer directory. Neither option is great, but the relative path is probably preferable to the duplicated configuration.
Remaining tasks
- Start code-sniffing the
composerdirectory. - Correct the existing coding standard violations. There are many, but phpcbf can help with most of them.
User interface changes
None.
API changes
None.
Data model changes
None.
Release notes snippet
n/a
| Comment | File | Size | Author |
|---|---|---|---|
| #27 | interdiff_26-27.txt | 2.3 KB | spokje |
| #27 | 3088730-27.patch | 9.08 KB | spokje |
Comments
Comment #2
jibranWe can add a root folder which will extend
core/phpcs.xml.dist.Comment #3
MixologicComment #4
mile23This moves the phpcs.xml.dist file to the root directory (out of the core directory), and modifies the composer.json phpcs script to use this new location.
This will likely break the phpcs plugin from DrupalCI, because
DrupalCI\Build\Codebase\CodebaseInterface::getProjectConfigDirectory().Comment #5
MixologicNow that core's .git repo is no longer "the root of somebodies project", we can move core's config files to the root of the git repo.
However, I think we might need drupalci to be able to determine if the config file lives at /core, then use that, otherwise default to / so that we can test patches like the above.
But we also have a someday plan of #2943856: [meta] Reorganize Components so they are testable in isolation -> would that include validation steps like phpcs? Would it include things like their own drupalci.yml file? Phpunit.xml?
I filed:
https://www.drupal.org/project/drupalci_testbot/issues/3093912 but I think it bears some discovery on whether or not we want 'one phpcs to rule them all' or individual files per subtree, and how that would work going forward in conjunction with our other plans for 'testable in isolation'
Comment #6
greg.1.anderson commentedDo you know why core/assets/vendor/* is still being scanned for code style, even though this line in theory still excludes it?
We end up with 30k+ new standard violations with this patch; only a fraction of those are valid.
Comment #7
mile23The DrupalCI phpcs plugin ends up making a special case for core, where all relative paths start at core/ instead of ./
So therefore excluding a relative path means it starts at the wrong place.
I find it a little disheartening that core itself has 3150 CSS errors to begin with.
Comment #8
mile23Added parent. #2571965: [meta] Fix PHP coding standards in core, stage 1
Comment #9
Mixologicotoh, csslint isnt even the tool they want to use (stylelint is), so, maybe we should implement that change instead, and make sure it gets the right dir?
https://www.drupal.org/project/drupalci_testbot/issues/2866840
Comment #10
klausiI think this makes sense!
I think we should not change this. We also want to ignore those JS directories everywhere. That way our phpcs config file is a better template for others.
So do we need to fix the DrupalCI phpcs plugin first in #3093912: Add a shim to allow /core to move config to the root, and or, allow for multiple configs. or after this patch?
Comment #12
jungleComment #13
naresh_bavaskarJust rerolled the #4 patch for 9.1.x
Comment #15
tanubansal commentedPatch #13 is working fine on 9.1
This can be moved to RTBC
Comment #16
klausino need for the ending slash?
this should not be changed, we want to exclude those everywhere
Haha, I'm posting the same comment as before, but this has not been fixed yet.
We also need to clarify this: do we need to fix the DrupalCI phpcs plugin first in #3093912: Add a shim to allow /core to move config to the root, and or, allow for multiple configs. or after this patch?
Comment #17
anmolgoyal74 commentedAddressed #16.
Comment #18
greg.1.anderson commentedNote that although #17 shows as green, coding violations do not set the test results to "failed".
I suspect that the fact that this patch is changing the relative paths of files makes it appear to the test runner that an existing violation is a new violation (c.f. #6, #7). While we do not necessarily want to fix all of the existing violations throughout core here, we should fix anything in the Composer directory.
It might be useful to make a patch that turns on code sniffing only for the Composer directory and get everything that is reported there first, and then turn the other paths back on after that's finished.
Comment #19
longwaveDo we have to move phpcs.xml.dist and restructure everything that uses it here, or is that out of scope? We can just add
../composeras a path and that seems to work.In this patch I've also fixed all the coding standards violations in the composer directory.
Comment #22
daffie commentedComment #23
ankithashettyRerolled the patch in #19, thanks!
Comment #24
longwaveSome new errors, I think these are newly added sniffs since the patch in #19
Comment #25
vikashsoni commentedPatch not working in drpual-9.3.x-dev
Checking patch composer/Generator/PackageGenerator.php...
error: composer/Generator/PackageGenerator.php: No such file or directory
Checking patch composer/Plugin/ProjectMessage/Message.php...
error: composer/Plugin/ProjectMessage/Message.php: No such file or directory
Checking patch composer/Plugin/Scaffold/Git.php...
error: composer/Plugin/Scaffold/Git.php: No such file or directory
Checking patch composer/Plugin/Scaffold/Operations/AppendOp.php...
error: composer/Plugin/Scaffold/Operations/AppendOp.php: No such file or directory
Checking patch composer/Plugin/Scaffold/Operations/OperationData.php...
error: composer/Plugin/Scaffold/Operations/OperationData.php: No such file or directory
Needs to re-roll
Comment #26
spokje@vikashsoni patch #23 is against
9.4.x-devas stated in the Version select in the IS, so it not applying to9.3.x-devisn't an issue.However, the failing tests that @longwave pointed out in #24 are a problem.
Attached patch tries to fix those.
Comment #27
spokjeNew sniff, new problems.
Would love to moan about it, but I'm the one of the people that introduced the sniff...
Comment #28
spokjeComment #29
daffie commentedLooks good to me.
Comment #30
alexpottCommitted and pushed 01bd426e28 to 10.0.x and b5aa3eb643 to 9.4.x and 00e831d136 to 9.3.x. Thanks!
Backported to 9.3.x to keep the code aligned and there is no functional change to run-time.