Packages: Extract Eslint config package

[gziolo]

Description

This PR extract Eslint config to its own package to make it possible to publish to npm. This also helps us to get rid of a temporary hack (introduced in #5502) of having eslint folder in the root directory of Gutenberg.

Related WordPress JavaScript core chat where we discussed coding standards which should be updated (https://make.wordpress.org/core/2018/7/25/javascript-chat-summary-july-24th/):

• For multiline comments, we will stick to the current core standards. Aside from some personal preferences, no one raised a strong need to change them.
• We’ll remove all spacing exceptions from the JS standards on spacing.
• Yoda conditions will no longer be enforced for JS.
• We won’t allow any exceptions for strict equality. The current exceptions in the core JS standards will be removed.
• For multiline conditions we’ll enforce three rules (proposed by @youknowriad):
  • If the condition is short enough to fit in a line, just use a single line
  • If not, one condition per line separated from the opening/closing parenthesis
  • the operator position at the end
• For multiline conditions we’ll remove the indentation clause from the standards.
• The Gutenberg naming conventions will be added to the standards. See:
  • Documentation: Coding Guidelines: Prescribe specific camelCasing behaviors #7670
  • https://github.com/WordPress/gutenberg/blob/4263e556fc889206fee5b22d54a1cd910f4e586b/docs/reference/coding-guidelines.md
• CSS naming conventions also need to be normalized with core. This should be addressed separately.
• We’ll start enforcing trailing comma’s.
• With regard to variable declarations at the top of each function: var declarations should always be at the top, let and const shouldn’t. This is because var is hoisted, the others aren’t.
• ES5 (non-transpiled) code should still be able to meet standards. We decided to have two rulesets, one baseset and one set specifically for ESnext (transpiled) code. It should be possible to disable the ESnext ruleset for legacy code. This will also be very useful for plugin and theme authors.
• The ESnext specific standards still need some more exploration. These will be explored in a trac ticket or Github issue / PR. There is already a related PR here: Packages: Extract Eslint config package #7965
• We agreed the current JS in core should be updated to adhere as much as possible to the WordPress JS coding standards. This is also in line with the most recent practices regarding coding standards. We decided to at least fix what can be autofixed.

How has this been tested?

• npm run lint still passes.

Types of changes

Refactoring - no production code has changed.

Checklist:

• My code is tested.
• My code follows the WordPress code style.
• My code follows the accessibility standards.
• My code has proper inline documentation.

[ntwb]

This package is not the "default" ESLint config for WordPress, this package currently describes and uses the current Gutenberg coding standards, these coding standards do not reflect the current WordPress JavaScript coding standards and should not seek to represent that it is.

Side note: There are more instances of eslint-config-default that need to be changed to eslint-config-gutenberg that I did not add code comments that should also be updated.

[aduth]

From today's Core JS meeting, it was decided to hold off on progress here until divergences between the standards of Gutenberg and WordPress can be enumerated and reconciled.

[gziolo]

We should also address the following comment from @aduth #8132 (comment) as part of this PR:

Note for future reference in extracting rules: We should consider having separate rulesets for ES5 vs. ES2015+ .

Looks like this is already built-in to eslint-plugin-wordpress:

https://github.com/WordPress-Coding-Standards/eslint-plugin-wordpress#available-rulesets

(Confused why there's both a config and a plugin which includes rulesets)

[gziolo]

I rebased this PR with the latest master changes. In addition I introduced the following changes:

• renames @wordpress/eslint-config-default to @wordpress/eslint-config
• inlined all rules for eslint-plugin-wordpress to avoid using git link

[gziolo]

Next steps we agreed on today during WordPress Core JavaScript weekly chat (https://make.wordpress.org/core/2018/11/27/javascript-chat-summary-november-27-2018/):

• publish the new @wordpress/eslint-config package.
• shortly after, or around the same time, publish a make/core post outlining proposed changes to the WordPress javascript standards and references the new published package as the codified representation of them.
• the post invites feedback/comments on the proposed changes and responses will help tailor how the package is iterated on and also what gets updated in the official javascript standards documentation for WordPress after a week of comments.

Out of date, out of touch ;)

[youknowriad]

Do we already follow all the discussed guidelines? I'm surprised there's no change in or formatting.

[gziolo]

Do we already follow all the discussed guidelines? I'm surprised there's no change in or formatting.

It should be closely examined again, but as far as I'm aware all those changes were proposed to make coding styles used in Gutenberg to become a new standard.

[gziolo]

It turned out plugin:jest/recommended includes the related env and plugins config :)

https://github.com/jest-community/eslint-plugin-jest/blob/master/index.js#L35-L52

[gziolo]

/cc those who discussed at the last WordPress core JavaScript meeting: @aduth @afercia @herregroen @nerrad @omarreiss @youknowriad

[ntwb]

A couple of inline suggested changes for ESLint spelling, otherwise 👍

[gziolo]

It might take some time until we publish the alpha version of this package. It probably all depends when WordPress RC is released.