no-magic-numbers false negatives on invalid array indexes

[mdjermanovic]

Tell us about your environment

• ESLint Version: 7.0.0-alpha.0
• Node Version: v12.14.0
• npm Version: v6.13.4

What parser (default, Babel-ESLint, etc.) are you using?

default

Please show your full configuration:

Configuration

module.exports = {
    parserOptions: {
        ecmaVersion: 2020
    },
};

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

/* eslint no-magic-numbers: ["error", { ignoreArrayIndexes: true }] */

a[2.5];

a[-3];

a[10n];

eslint index.js

What did you expect to happen?

When ignoreArrayIndexes is set to false this code has 3 errors, so I would expect the same when this option is set to true.

2.5 and -3 are not array indexes.

Less sure about the bigint since it will indeed get the element at index 10. Still, a bigint there looks more like member access than array index.

What actually happened? Please include the actual, raw output from ESLint.

no errors.

Are you willing to submit a pull request to fix this bug?

Yes.

[kaicataldo]

I think it makes sense to warn on the first two (and assume this is a computed property name on a), but since the BigInt is a valid index, I think that should be ignored.

[kaicataldo]

Forgot to mention that I'm not seeing the BigInt example in our demo.

[mdjermanovic]

Forgot to mention that I'm not seeing the BigInt example in our demo.

I didn't include a demo link because of that, but forgot to mention why.

Online demo is still v.6.8.0 and the rule wasn't checking bigint literals at that point (#12701 was merged later as a breaking change), so the BigInt part of the issue is at the moment observable only in v7.0.0-alpha.0.

I think it makes sense to warn on the first two (and assume this is a computed property name on a), but since the BigInt is a valid index, I think that should be ignored.

Agreed, wasn't really sure about that.

I'll fix the option to have the following behavior: treat all non-negative integer numbers and non-negative bigints as array indexes (assuming that unary minus before the literal is a part of the number/bigint).

[kaicataldo]

Online demo is still v.6.8.0 and the rule wasn't checking bigint literals at that point (#12701 was merged later as a breaking change), so the BigInt part of the issue is at the moment observable only in v7.0.0-alpha.0.

Ah, right, that makes sense!

I'll fix the option to have the following behavior: treat all non-negative integer numbers and non-negative bigints as array indexes (assuming that unary minus before the literal is a part of the number/bigint).

Sounds good to me.