Upgrade to wp-prettier 2.2.1

[jsnajdr]

This is how Calypso codebase gets reformatted after upgrade to wp-prettier@2.2.1. I was originally testing with a local build, so the PR contained only the formatting changes and not the package upgrade. Later after verifying the upgrade both with Calypso and Gutenberg, I published wp-prettier@2.2.1-beta-§ to NPM and updated our package.json accordingly.

Notable changes:

a( b, (
  c,
  d
) => {
  e();
} );

no longer breaks the argument list of the inline arrow function and formats the code more nicely:

a(
  b,
  ( c, d ) => {
    e();
  }
);

This is an expected change that's been announced in Prettier 2.2.0 changelog.

Then there's fixed arrow function formatting inside Styled Components template literal:

styled(A)`
  @media (aaaaaaaaaaaaa) {
	z-index: ${(props) => (props.isComplete ? '1' : '0')};
  }
`;

Also expected, it's a bug fixed in 2.1.2 (prettier/prettier#9136) after our report.

Finally, Prettier stopped breaking type parameters in long class ... extends statements.

Before:

export default class SiteLevelPurchasesErrorBoundary extends React.Component<
  SiteLevelPurchasesErrorBoundaryProps
>

After:

export default class SiteLevelPurchasesErrorBoundary extends React.Component< SiteLevelPurchasesErrorBoundaryProps >

[matticbot]

Test live: https://calypso.live/?branch=try/wp-prettier-2.2.1

[matticbot]

This PR does not affect the size of JS and CSS bundles shipped to the user's browser.

Generated by performance advisor bot at iscalypsofastyet.com.

[scinos]

All changes make sense to me.

[jsnajdr]

Thanks @scinos for approving 👍 Now I also published the package to NPM and added another commit that upgrades wp-prettier to the new package. Can you please have a second look before I merge the PR?

[sirreal]

Visual inspection of changes looks good, thanks 👍

[scinos]

LGTM. Code Style errors seems to be unrelated.

[jsnajdr]

Code Style errors seems to be unrelated.

One of them are missing JSDoc params that are trivial and zero-risk to fix. So I pushed a commit with that.

The second file with violations is more interesting. It's in an error boundary React component written by @nbloomf where a TypeScript ESLint rule complains about return types of methods not being declared on the component's methods:

Missing return type on function. (@typescript-eslint/explicit-module-boundary-types)

In general, this rule makes sense: it encourages that types that are part of public APIs are explicitly named and declared, instead of just being anonymous types inferred from code.

But here, the offending methods are methods of the ReactComponent superclass:

• getDerivedStateFromError
• componentDidCatch
• render

It's already pretty clear what the types are supposed to be, and they have names and definitions. There's no need to repeat what a return type of render is. I think that the rule is overreaching here. Cc @sirreal if he has any insights.