Add config option for allowing extra spaces around elements and arguments in JavaScript

Previously proposed in #1303 and locked as resolved by bot .

Description

This applies only to JavaScript/TypeScript code. It would be similar to the new Enforce Single Attribute Per Line option introduced with #5501 in Prettier 2.6.0.

WordPress JavaScript coding conventions for spacing for historical reasons promote different formatting styles around spaces in JavaScript. The short version of the approach looks as follows:

Use spaces liberally throughout your code. “When in doubt, space it out.”

This is the only feature that isn’t supported by Prettier.

In practice, code formatting in WordPress projects look as follows:

Always include extra spaces around elements and arguments:

array = [ a, b ];
foo( arg );`
foo( 'string', object );
foo( options, object[ property ] );
foo( node, 'property', 2 );
prop = object[ 'default' ];
firstArrayElement = arr[ 0 ];

if ( condition ) {
   doSomething( 'with a string' );
} else if ( otherCondition ) {
    otherThing( {
        key: value,
        otherKey: otherValue
    } );
} else {
    somethingElse( true );
}

// Unlike jQuery, WordPress prefers a space after the ! negation operator.
// This is also done to conform to our PHP standards.
while ( ! condition ) {
    iterating++;
}

let i;
for ( i = 0; i < 100; i++ ) {
    object[ array[ i ] ] = someFn( i );
    $( '.container' ).val( array[ i ] );
}
 
try {
    // Expressions
} catch ( e ) {
    // Expressions
}

Alternative approaches considered

Using Prettier’s fork and npm aliases

This is where we are now for WordPress projects with Prettier’s fork that adds a --paren-spacing option. We’ve been maintaining it for over 4 yours now.

It’s possible to use all powerful integration from Prettier ecosystem with npm aliases:

https://github.com/WordPress/gutenberg/blob/d48b6bb7f2324db82ac6d3bc87b9a71e542d107f/packages/scripts/package.json#L75

"dependencies": {
    "prettier": "npm:wp-prettier@2.6.2"
}

However npm aliases are completely unreliable in npm, and it became only worse since new behavior for peer dependencies was added in npm 7. More details in https://github.com/WordPress/gutenberg/issues/21872. I guess npm aliases are fine for a consuming project as a workaround, but using them in packages distributed on npm creates random errors.

Changing coding conventions in WordPress projects

It was suggested in a few places in other issues in Prettier repository. It didn’t seem a viable option so far despite several tries like https://github.com/WordPress/gutenberg/pull/37607 and Proposal: Changes to JavaScript Coding Standards for Full Prettier Compatibility.

Plugins: allow overriding internal plugins, e.g., printer for JS or CSS

It was filed in #5919. The idea would be to create a plugin that exports a custom printer for JS/TS that replaces what Prettier offers in the core. This way, we could customize the formatted code. It isn’t ideal, but that removes the maintenance work from the Prettier project for custom options like the one proposed. We’ve been maintaining a Prettier’s fork that adds a --paren-spacing option for the last four years. We could turn it into a plugin and publish it to NPM as prettier-plugin-wordpress.

[JanJakes]

I was asked why I used 👎 for the original issue so let me share my answer also here.

As a disclaimer, I work at Automattic, but this opinion is 100% my personal one:

---

I do genuinely believe Prettier should add no such option. I think it would be harmful to both Prettier (fragmentation, violating their philosophy) and WordPress (never aligning with the rest of the ecosystem).

Therefore, I think they should not accept it. Prettier is opinionated, they always had the philosophy of never adding any configuration and I believe it’s a good philosophy. If they add options like this then it’s no longer opinionated and it’s no longer unifying the JS ecosystem. Coding styles will become fragmented again and people will discuss them forever again.

Prettier styles may not be perfect but they are very good. In the JS world, almost every larger project uses these and it would be only beneficial for WordPress to become less of a stranger to the rest of the industry.

The issue to adopt Prettier as it is had huge support (19 vs. 3) and I think we should be asking why and how it ended up being thrown out of the window rather than whether Prettier should do what WordPress wants. If a popular suggestion was somehow blocked, we should be reopening a discussion with those who are blocking it. Personally, I think it’s WordPress that has a lot to catch up on modern coding styles and alignment with the industry standards.

[ockham]

I wouldn’t make this about readability, which I find indeed a very subjective argument. (Neither myself nor @gziolo would mind dropping the extra spaces; but that is not what the WordPress community wants.)

I’d rather look at it from the angle that the WordPress ecosystem is fairly large and mature, and has used these conventions for a while — in both JS and PHP. I believe we’ve done what we can on our end:

• We’ve maintained our fork for four years, and
• we’ve tried to convince the community to abandon the extra spacing for full compatibility with Prettier. But, alas, the community has rejected that proposal.

Now it can of course be argued (as others have done) that that’s not Prettier’s problem but WordPress’! And that’s fair. However, I’d like to point out two things:

1. This is an ecosystem that comprises not only WordPress itself („Core“) but also thousands of plugins and themes.
2. WordPress code isn’t JS only, but typically also includes a lot of PHP. Our PHP Coding Standards mandate the extra space. Any conversation about dropping the extra space from our JS code will inevitably lead to a debate about consistency with our PHP code (which played a role in the rejection of the proposal), or potentially about changing the PHP code style accordingly — an ever bigger conversation that’s likely to face even more pushback.

So we find ourselves at a bit of an impasse. I know it’s against the spirit of Prettier to offer excess configurability, but I’d go as far as to say that this is not your typical “more config options plz!” request: I’m not aware of any other FLOSS projects with a similar reach (43% of the Web runs on WordPress) and well-established Coding Standards that are just one extra option away from being able to fully use Prettier to format their JS code. Thus, I’d kindly ask that you reconsider adding a --parent-spacing option after all.

Thank you ❤️