Rules for space indentation instead of tabs, specifically in multiline arrays

[pdewouters]

Is your feature request related to a problem?

Enforcing spaces for indentation

Describe the solution you'd like

I want to introduce WP standards in a codebase that is using spaces for indentation, so instead of converting all indentation to tabs, I'd like to enforce 2 spaces as per existing style.
this config gets me nearly there https://gist.github.com/pdewouters/39d6b4f1c2d60e5c1538163774c8ed18

But I still get some errors related to array indentation, it thinks it should be 4 spaces instead of 2.

function update_admin_labels() {
  wp_register_script(
    'update-some-admin-labels-js',
    plugins_url( 'my-plugin/js/update-some-admin-labels.js' ),
    [
      'wp-plugins',
      'wp-edit-post',
      'wp-element',
      'wp-components',
      'wp-i18n',
    ],
    1
  );
}
add_action( 'init', 'pdate_admin_labels' );

Additional context (optional)

See screenshot: the first line has no errors because it has 4 spaces indent but the next ones throw an error. It should be the reverse

• I intend to create a pull request to implement this feature.

[jrfnl]

@pdewouters As is clearly mentioned in the templates: please do not post screenshots, post a code sample the report can be tested with.

As things are, this is not actionable.

[dingo-d]

This looks like a discussion topic, not an issue with WPCS. Can you open this as a discussion instead @pdewouters ?

[pdewouters]

@dingo-d where are the discussions?

[dingo-d]

You don't see the https://github.com/WordPress/WordPress-Coding-Standards/discussions link? 🤔

[pdewouters]

I do now, thanks

[jrfnl]

@pdewouters Okay, so this is not an issue with the sniff, but related to a quirk in PHPCS (which will be fixed/changed in PHPCS 4.0).

Basically, a "config" setting, like tab-width, cannot be easily overruled from within a custom ruleset.

In other words, even with the config you posted, the tab-width is still set to 4 as it is inherited from WPCS, which is why the sniff behaves as it does.

There are two options to get round this for now (until PHPCS 4.0 has been released):

1. Set the tab-width on the command line. Command line overrules all, so running PHPCS like so phpcs --tab-width=2 will work and pick up your custom ruleset for everything else.
   You can encodify this in a Composer script if you want to help contributors to a project to run the command like this.
2. As part of the PHPCS quirks, setting the tab-width from within another included ruleset will actually overrule the WPCS setting, but only if that ruleset is included before WPCS. See the code example below on how to do that.

Create a separate PHPCS config file which only contains the tab-width setting and name it something like tabwidth.xml.

<?xml version="1.0"?>
<ruleset xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" name="Tabwidth" xsi:noNamespaceSchemaLocation="https://raw.githubusercontent.com/PHPCSStandards/PHP_CodeSniffer/master/phpcs.xsd">

  <arg name="tab-width" value="2"/>

</ruleset>

Include that ruleset in your [.]phpcs.xml[.dist] file before including the WordPress ruleset, so something like:

<?xml version="1.0"?>
<ruleset xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" name="MyConfig" xsi:noNamespaceSchemaLocation="https://raw.githubusercontent.com/PHPCSStandards/PHP_CodeSniffer/master/phpcs.xsd">

  <rule ref="tabwidth.xml"/>
  <rule ref="WordPress"/>
</ruleset>

Now, your tab width will be correctly seen as 2 and things will work as you expect.

Hope this helps.

[pdewouters]

oh wow, ok. Thanks for the detailed explanation and solution, much appreciated