[wp-trac] [WordPress Trac] #44600: Update WPCS to 1.0.0, and enforce coding standards

[WordPress Trac]

#44600: Update WPCS to 1.0.0, and enforce coding standards
------------------------------+-------------------------------
 Reporter:  pento             |       Owner:  pento
     Type:  task (blessed)    |      Status:  assigned
 Priority:  normal            |   Milestone:  5.0
Component:  Build/Test Tools  |     Version:  trunk
 Severity:  normal            |  Resolution:
 Keywords:                    |     Focuses:  coding-standards
------------------------------+-------------------------------

Comment (by pento):

 Replying to [comment:7 jrf]:
 > I can understand fixing WPCS to a certain version, though as WPCS will
 be using semantic versioning, I think `~1.0.0` can safely be used instead
 of `1.0.0` as - if there will be a 1.0.x release, it will only contain bug
 fixes. New sniffs will not be introduced in patch releases, only in
 minors/majors.

 Solely for reproducibility. I'm not concerned about new sniffs, but if a
 sniff bugfix changed the behaviour, it would cause problems for anything
 relying on that behaviour to not change.

 > I don't understand why the DealerDirect Composer should be fixed to a
 certain version. This is a plugin to handle setting the PHPCS
 `installed_paths`, so it should be fine to always use the latest version
 available.

 For consistency. Whilst building Gutenberg, we've found it to be far safer
 to use exact version numbers for all packages, as behaviour can
 unexpectedly change, even in bugfix releases. Rather than choose packages
 that can be safely allowed to use the latest version, it's better to fix
 all version numbers, and upgrade as we need.

 > `PEAR.Functions.FunctionCallSignature` config: The `requiredSpaces`
 properties are already set to `1` in the `WordPress-Core` WPCS ruleset, so
 you don't need to set them in the custom ruleset.

 Huh, I thought it broke something when I tried to do that, but it works
 fine. Guess I must've messed something else up in earlier testing. 🙂

 > * As for the `allowMultipleArguments` property for that same sniff, I
 have two questions:
 >     - Should that configuration be set in the custom ruleset or in the
 `WordPress-Core` ruleset ?

 Yah, it can be moved to `WordPress-Core`. Can WPCS releases move a bit
 faster than they have previously? Waiting weeks for a new release to make
 a config change is not ideal.

 >     - And is that configuration only needed for correctly *fixing*
 things or should the related error also be thrown when running `phpcs` ?

 Sure, it should probably throw there, too.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/44600#comment:8>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform