Add a package to hold our coding standard

[anomiex]

Changes proposed in this Pull Request:

This moves the code for custom Jetpack phpcs sniffs into a new package in the monorepo, which will make it easier in the future to import additional sniffs and add tests. It'll also make it easy to reuse the coding standard in any other code repo we might wind up with.

This also adds some tests, and has the WordPress sniffs be pulled in via the Jetpack standard instead of being pulled in on their own.

Jetpack product discussion

None directly, but see p9dueE-1Y9-p2 for the proposal this cleanup is motivated by.

Does this pull request change what data or activity we track or use?

No.

Testing instructions:

• Verify that this doesn't change any sniffs reported by composer php:lint or the like. You might do that by
  • Check out a clean copy of master. Run composer install && composer php:lint -- --report-file=/tmp/report.old
  • Pull in this PR. Run composer install && composer php:lint -- --report-file=/tmp/report.new
  • Compare /tmp/report.old and /tmp/report.new to see if any unexpected changes were made.

Proposed changelog entry for your changes:

• This is developer-only, so probably no need for a changelog entry.

[jetpackbot]

Scheduled Jetpack release: November 10, 2020.
Scheduled code freeze: November 3, 2020

E2E results is available here (for debugging purposes): https://jetpack-e2e-dashboard.herokuapp.com/pr-17405

Thank you for the great PR description!

When this PR is ready for review, please apply the [Status] Needs Review label. If you are an a11n, please have someone from your team review the code if possible. The Jetpack team will also review this PR and merge it to be included in the next Jetpack release.

Generated by 🚫 dangerJS against cadfcaa

[kraftbj]

This can replace #15693 in principle. There is a rule in there that we'd need to bring over, but I like this approach to creating the package more than what I had.

[anomiex]

This can replace #15693 in principle. There is a rule in there that we'd need to bring over, but I like this approach to creating the package more than what I had.

Ooh, someone tried this before. Nice! Looking for differences... It looks like we did mostly the same things.

• I don't care which name might get used for the package.
• After some testing, I find that specifying <config> in ruleset.xml would be "opinionated" in the bad sense: it's impossible to override from .phpcs.xml.dist (until phpcs 4.0, see Change ruleset processing to be top-to-bottom instead of processing tags in groups squizlabs/PHP_CodeSniffer#2197).
  • Probably best to leave <arg>, <file>, and so on for .phpcs.xml.dist too.
• I'd rather not do namespaces like Automattic\Jetpack\CodingStandards\Jetpack\Sniffs\Commenting if Jetpack\Sniffs\Commenting or Automattic\Jetpack\Sniffs\Commenting is ok.
  • Looks like most of our packages do Automattic\Jetpack\... (autoloader is the only one that doesn't), so let's go with that here too.
• I'd like to see the new sniffs from Coding Standards: Add CS Package #15693 as a followup PR rather than being squashed into this one, much like I did with Import several phpcs sniffs from MediaWiki #17406). Seems cleaner to me that way.

[kraftbj]

Yup, I'm fine waiting to add rules until after this lands.

[kraftbj]

Let's give this a spin.