acquia / blt-phpcs

Acquia BLT PHPCS plugin

Acquia BLT PHP_CodeSniffer

This is an Acquia BLT plugin providing integration with PHP_CodeSniffer and Acquia’s Coding Standards.

This plugin provides a set of commands in the validate:phpcs namespace that use PHP_CodeSniffer to check for coding standard violations.

When first installed, it will create a default phpcs.xml file utilizing Acquia’s Coding Standards if one does not exist.

This plugin is community-supported. Acquia does not provide any direct support for this software or provide any warranty as to its stability.

Installation and usage

To use this plugin, you must already have a Drupal project using BLT 12 or higher.

In your project, require the plugin with Composer:

composer require --dev acquia/blt-phpcs

License

Copyright (C) 2020 Acquia, Inc.

This program is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License version 2 as published by the Free Software Foundation.

This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

blt-phpcs's Issues

Need Git pre-commit validation

Update GitIgnore and Remove Composer.lock

it seems like we should NOT commit the composer.lock file for this project (to stay inline with the parent BLT repo's stance on this).

Update to Support Composer 2.x

Trying out composer 2.x with this plugin results in:

The "acquia/blt-phpcs" plugin was skipped because it requires a Plugin API version ("^1.1") that does not match your Composer installation ("2.0.0"). You may need to run composer update with the "--no-plugins" option.

This is semi urgent since BLT 12.x theoretically supports composer 2.x as of acquia/blt#4144

Validation issues between dev-master and 1.0

If I install this plugin at commit #ddaa71b (or, from dev-master in general) and run blt validate:phpcs I get a pretty minimal set of issues returned. On the other hand, if I install at ^1 and land on 1.0.0 I get dozens of additional issues.

From my manual code review, it would appear that the 1.0.0 version gives a much more accurate representation of what's "going on" in the codebase.

I'm concerned that something that has been merged since the 1.0.0 release has caused a regression.

I have customer files I can share internally with you @danepowell and some code bases to look at that I can't post here, but I do worry that something is up!

For context:

• dev-master returns roughly 20 lines of output
• ^1 returns roughly 300 lines of output (on the exact same codebase with no other changes other than changing the acquia/blt-phpcs version)

Validate PHPCS is flagging Javascript with true/false/null case error

We are in the process of upgrading to PHP 8.1 on our Drupal 9 site. When I run blt validate:phpcs on the site, I have javascript which is being flagged with

15 | ERROR | [x] TRUE, FALSE and NULL must be uppercase; expected "TRUE" but found "true"

When I fix them, and try to run the code in the browser, I get

Uncaught ReferenceError: TRUE is not defined

When faced with the conundrum of whether or not to set up a weird way for both "true" and "TRUE" to mean the same thing in my code, I have decided to just add all of my javascript to <exclude-pattern> in the phpcs.xml.dist instead.