Add ESLint comma-dangle rule

[nylen]

Enforce trailing comma syntax for JavaScript arrays and objects:

return [
  'nice',
  'simple',
  'keys',
];

return {
  not: {
    so: {
      simple: {
        keys: {},
      },
    },
  },
};

Closes #612 - more discussion over there.

[aduth]

Hoping this was a simple eslint --fix, because recent shuffling caused a number of conflicts 😬

[aduth]

I know it's a style preference and all, but looking through the changes, I just can't help but feel that all the extra noise is not worth the insignificant benefit it brings.

[nylen]

Hoping this was a simple eslint --fix

Yes :)

I know it's a style preference and all, but looking through the changes, I just can't help but feel that all the extra noise is not worth the insignificant benefit it brings.

I think this has a decent amount of practical benefit beyond just being a style preference. Quoting from #612:

From the WordPress coding standards for PHP:

Note the comma after the last array item: this is recommended because it makes it easier to change the order of the array, and makes for cleaner diffs when new items are added.

Scattered throughout the JavaScript docs numerous times and to paraphrase quite heavily is:

https://make.wordpress.org/core/handbook/best-practices/coding-standards/javascript
These are for consistency between the PHP and JavaScript files in the WordPress codebase.

Also, part of the reason you're seeing so much churn here is simply that we have a whole lot of code :)

[aduth]

Sorry, I didn't mean to suggest the benefits are purely cosmetic. I understand they exist, but I don't find them particularly compelling. And it's not so much the number of changes, rather that it feels unnatural in many circumstances. For example, I'd never have thought to put a comma here:

https://github.com/WordPress/gutenberg/blob/34586fc/blocks/library/embed/index.js#L82

Perhaps it will just take time to adjust. And at least we have ESLint to enforce it if it comes to be overlooked.

[nylen]

I still think we should do this. Your example doesn't look too bad to me, in fact I think it's pretty natural and also serves to indicate "yes there's more stuff above at this nesting level".

Granted I probably wouldn't be pushing for this change except for the fact that I've already adopted this rule in my preferred coding style personally... though I do find it quite nice to have cleaner diffs when modifying lists of things, like connect properties or component arguments for example.

To update this PR later on (starting with a clean working tree):

git fetch origin && git checkout origin/master -B master
git show add/eslint-comma-dangle .eslintrc.json | git apply
git checkout -B add/eslint-comma-dangle
./node_modules/.bin/eslint . --fix
git commit -am 'Add ESLint `comma-dangle` rule'
git push -f

[ntwb]

LGTM

[ntwb]

"These are for consistency between the PHP and JavaScript files in the WordPress codebase."

If we're going to do this, may as well do it now, the change no doubt will affect existing PRs and they will need to be updated.

I'm happy to update the changes back to the handbook and add this rule to eslint-config-wordpress today.

Unfortunately I missed the #Core JS chat last night, but I've caught up and read through the chat, if we're going to start updating the JS coding standards, then updating one of those said standards this week in preparation for next weeks chat would be 👌 . I say this as it will give us (rather me) an opportunity to show the workflow and processes of what's required to make a change to the standards.