Follow-up to #2571965: [meta] Fix PHP coding standards in core, stage 1

Problem/Motivation

Step by step we are going to add new rules to phpcs.xml.dist
But the approach to exclude sniffs not related to Drupal CS or postponed is different

  1. sniffs excluded by exclude wrapper
    http://cgit.drupalcode.org/drupal/tree/core/phpcs.xml.dist#n54
  2. sniffs added torule with severity
    http://cgit.drupalcode.org/drupal/tree/core/phpcs.xml.dist#n147

OTOH

We have two groups of sniffs that we need to exclude:

  • postponed sniffs, to be removed and fixed later
  • not related to Drupal CS Sniffs

Proposed resolution

Rewrite phpcs.xml.dist using following approach:

  • all not related to Drupal CS Sniffs add with <exclude> wrapper and commit it for ever :)
  • all postponed sniffs which will be fixes later add using <severity>0</severity> directive. This directive is more related to goal that we need: "Hide errors of postponed sniffs"

Comments

andriyun created an issue. See original summary.

andriyun’s picture

andriyun commented
Title: [meta] Fix coding standards in core » Sniff definitions approach in phpcs.xml.dist
andypost’s picture

andypost
he/him
Primary language Russian
commented

Yep, next step is polishing - removing of warnings

andriyun’s picture

andriyun commented
Issue summary: View changes
mile23’s picture

mile23
Primary language English
Location Seattle, WA
commented
Title: Sniff definitions approach in phpcs.xml.dist » Sniff definitions approach in phpcs.xml.dist: exclude vs severity

There are two goals for this process:

  1. Eventually just specify the Drupal standard from Coder without any exceptions or severity modifications.
  2. Short of that, we should emulate Coder's Drupal/ruleset.xml. So however ruleset.xml defines an exclusion or severity level should be the way it's defined for core.

So if there's an exclude that doesn't appear in ruleset.xml, then the solution is to fix the CS error in core, so we can remove the exclusion.

In the example given above at http://cgit.drupalcode.org/drupal/tree/core/phpcs.xml.dist#n54, there are a bunch of exclusions for Drupal.Commenting.FunctionComment. These are being addressed in #2572645: [Meta] Fix 'Drupal.Commenting.FunctionComment' coding standard so eventually they'll go away.

ivan berezhnov’s picture

ivan berezhnov commented
Issue tags: +CSKyiv18

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.0-alpha1 will be released the week of January 17, 2018, which means new developments and disruptive changes should now be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.7.x-dev

Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

jonathan1055’s picture

jonathan1055 commented

This is a good idea. Having two sections in phpcs.xml.dist, the first being described as "we are not ever going to follow these sniffs" and have them excluded. The second section could be described as "Yes we like these, and want to follow them, and are slowly working through fixing core". These would have severity 0 whilst the work is being done, and then that would be removed when core follows the standard.

Overall this will mean that phpcs.xml.dist shrinks as we get more are more sniffs passing in Core. Currently, the file expands each time a new sniff passes.

Historically, it has been done this way (only adding a sniff when it passes in core) so that if Coder adds a brand-new sniff we don't have Core immediately failing the tests. However, I think this should not be a problem. The version of Coder applicable to Core is generally only upgraded when moving to a new minor release, i.e. 9.4 to 9.5. If the first runs of core at a new minor release fail for new Coder sniffs then that is precisely and exactly a good time to add these new sniffs to the second section, with severity 0. This can be done very quickly and easily so it would not mean that Core tests fail for very long.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

quietone’s picture

quietone commented
Parent issue: #2571965: [meta] Fix PHP coding standards in core, stage 1 » #3553320: [meta] Fix PHP coding standards in core, stage 2

Version: 11.x-dev » main

Drupal core is now using the main branch as the primary development branch. New developments and disruptive changes should now be targeted to the main branch.

Read more in the announcement.