"array-element-newline" must handle ignored elements when destructuring arrays

Tell us about your environment

• ESLint Version: 6.8.0
• Node Version: 13.6.0
• NPM Version: 6.13.4
• Parser @typescript-eslint

Please show your full configuration:

Configuration

```js module.exports = { env: { browser: true, node: true, es6: true, }, extends: [ 'airbnb', 'plugin:react/recommended', 'plugin:import/typescript', ], globals: { PropTypes: false, React: false, uiVersion: false, }, parser: '@typescript-eslint/parser', parserOptions: { ecmaFeatures: { jsx: true, }, ecmaVersion: 2018, sourceType: 'module', }, plugins: [ '@typescript-eslint', 'react', 'react-hooks', 'sort-destructure-keys', ], rules: { 'array-bracket-newline': ['error', { 'multiline': true, 'minItems': 3, }], 'array-element-newline': ['warn', { 'multiline': true, 'minItems': 3, }], 'arrow-body-style': 'off', 'arrow-parens': 'off', 'camelcase': ['warn', { allow: ["^UNSAFE_", "doc_count", "^active_"], }], 'comma-dangle': ['warn', 'always-multiline'], 'consistent-return': ['warn', { treatUndefinedAsUnspecified: true }], 'func-names': ['warn', 'as-needed'], 'function-paren-newline': ['warn', 'consistent'], 'implicit-arrow-linebreak': 'off', 'indent': ['warn', 4, { ArrayExpression: 'first', CallExpression: { arguments: 'first' }, flatTernaryExpressions: true, FunctionDeclaration: { parameters: 'first' }, FunctionExpression: { parameters: 'first' }, ignoreComments: true, ignoredNodes: [ 'ConditionalExpression', 'JSXAttribute', 'JSXClosingElement', 'JSXElement', 'JSXElement > *', 'JSXEmptyExpression', 'JSXExpressionContainer', 'JSXIdentifier', 'JSXMemberExpression', 'JSXNamespacedName', 'JSXOpeningElement', 'JSXSpreadAttribute', 'JSXSpreadChild', 'JSXText', 'TemplateLiteral > *', ], ImportDeclaration: 'first', MemberExpression: 1, ObjectExpression: 'first', SwitchCase: 1, VariableDeclarator: 'first', }], 'multiline-ternary': ['warn', 'always-multiline'], 'no-console': ['warn', { allow: [ 'info', 'warn', 'error', ] }], 'no-debugger': 'warn', 'no-fallthrough': ['warn', { commentPattern: 'break[\\s\\w]*omitted', }], 'no-nested-ternary': 'off', 'no-unneeded-ternary': 'warn', 'no-unused-expressions': ['warn', { allowShortCircuit: true, allowTaggedTemplates: true, allowTernary: true, }], 'no-var': 'error', // Must use const or let. 'object-property-newline': ['warn', { // allowAllPropertiesOnSameLine: false, }], 'object-curly-newline': 'warn', // ['warn', { // ObjectExpression: { // 'multiline': true, // 'minProperties': 2, // }, // ObjectPattern: { // 'multiline': true, // 'minProperties': 2, // }, // ImportDeclaration: { // 'multiline': true, // 'minProperties': 2, // }, // ExportDeclaration: { // 'multiline': true, // 'minProperties': 2, // }, // }], 'operator-linebreak': ['warn', 'after', { overrides: { '?': 'before', ':': 'before', } }], 'padded-blocks': 'error', 'semi': ['warn', 'always'], 'sort-keys': ['warn', 'asc', { caseSensitive: false, natural: true, }], 'quotes': ['warn', 'single'], 'import/extensions': 'off', 'react/jsx-closing-bracket-location': ['warn', 'props-aligned'], 'react/jsx-filename-extension': ['warn', { extensions: [ '.js', '.jsx', '.tsx', ], }], 'react/jsx-first-prop-new-line': ['warn', 'multiline'], 'react/jsx-fragments': ['error', 'element'], 'react/jsx-indent': ['warn', 2, { checkAttributes: true, indentLogicalExpressions: true, }], 'react/jsx-indent-props': ['warn', 2], 'react/jsx-max-props-per-line': ['warn', { maximum: 1, when: 'multiline', }], 'react/jsx-one-expression-per-line': ['warn', { allow: 'single-child', }], 'react/jsx-sort-default-props': 'error', 'react/jsx-sort-props': ['warn', { ignoreCase: true, }], 'react/jsx-tag-spacing': ['warn', { closingSlash: 'never', beforeSelfClosing: 'always', afterOpening: 'never', beforeClosing: 'never', }], 'react/jsx-wrap-multilines': ['error', { declaration: 'parens-new-line', assignment: 'parens-new-line', return: 'parens-new-line', arrow: 'parens-new-line', condition: 'parens-new-line', logical: 'parens-new-line', prop: 'parens-new-line', }], 'react/no-did-mount-set-state': 'warn', 'react/no-did-update-set-state': 'warn', 'react/no-direct-mutation-state': 'warn', 'react/no-multi-comp': 'warn', 'react/no-unknown-property': 'warn', 'react/sort-comp': 'warn', 'react/sort-prop-types': 'error', 'react/prop-types': 'off', 'sort-destructure-keys/sort-destructure-keys': ['warn', { caseSensitive: false, }], '@typescript-eslint/explicit-function-return-type': 'off', '@typescript-eslint/explicit-member-accessibility': 'off', }, settings: { 'import/resolver': { node: { paths: ['./src/packages'] }, }, react: { version: 'detect', }, }, } ```

What did you do? Please include the actual source code causing the issue, as well as the command that you used to run ESLint.

As continuation of the fix for #12756, I expect each element (ignored or not) in a new line. However, while working on that other issue, I’ve realised different users may prefer having consecutive ignored elements (i.e. consecutive commas) in the same line. Examples of different cases:

const [
    ,, // consecutive commas. valid?
    configPath = 'config.json',
    authFilePath = 'freshbooks.auth',
] = process.argv;
 
// vs

const [
    ,
    , // enforce separate lines?
    configPath = 'config.json',
    authFilePath = 'freshbooks.auth',
] = process.argv;

My only right now opinion is we should not allow consecutive commas after a valid (as of before this “fix”) line.

Example:

const [
    configPath = 'config.json', // good old comma
    , // this comma is now valid as an ignored element.
    authFilePath = 'freshbooks.auth',,, // these two extra commas should be in the next line,
    // either together or lines of their own.
] = process.argv;

This issue is meant to open a community discussion on what the handling for successive commas should be; whether it should be a config in this rule or not.

Afterwards, I’ll try to implement the agreed changes, unless someone else wants to take a stab at it.

[mdjermanovic]

I think the expected behavior would be for the rule to treat each comma as if it were an element in the array:

/*eslint array-element-newline: ["error", "always"]*/

// Correct
const [
    configPath = 'config.json',
    ,
    authFilePath = 'freshbooks.auth',
    ,
    ,
] = process.argv;

What would be the correct formatting if we also have comma-style with the option first. Maybe the following:

/*eslint array-element-newline: ["error", "always"]*/
/*eslint comma-style: ["error", "first", { 
    "exceptions": { "ArrayPattern": false }
}]*/

// Correct ?
const [
    configPath = 'config.json'
    ,
    ,authFilePath = 'freshbooks.auth'
    ,
    ,
    ,
] = process.argv;

I’m not sure if this is the expected code, especially about those 3 commas at the end, but perhaps we should analyze could there be any conflicts and how will the fixers for these two rules together transform the code into the desired state (this, or some other), e.g., which one will put the linebreak between 'config.json' and the comma after.

Currently, comma-style with first fixes the quoted code to:

/*eslint array-element-newline: ["error", "always"]*/
/*eslint comma-style: ["error", "first", { 
    "exceptions": { "ArrayPattern": false }
}]*/

const [
    configPath = 'config.json',    
    ,authFilePath = 'freshbooks.auth',
    ,    
,] = process.argv;

The new array-element-newline behavior would probably want to put a linebreak before authFilePath:

/*eslint array-element-newline: ["error", "always"]*/
/*eslint comma-style: ["error", "first", { 
    "exceptions": { "ArrayPattern": false }
}]*/

const [
    configPath = 'config.json',    
    ,
    authFilePath = 'freshbooks.auth',
    ,    
,] = process.argv;

And there’s a conflict, comma-style wants authFilePath back to the comma. If PR #12772 allows that lone comma, there will be no conflicts and this will be the final state. But, this code looks more like the Comma Last style.

[kaicataldo]

We appreciate your help!

I would advocate for fixing it in a semver-minor bug fix PR

What I meant by this is that, while this will result in more errors being reported, that I think we should treat it as a bug fix and therefore releasable in a minor release (indicating non-breaking changes). You can read more about our semantic versioning policy here (and happy to explain if anything is unclear). That being said, we’ve begun work on our next major release and are currently able to make breaking changes.

Let’s see what others on the team have to say!