no-octal rule on NonOctalDecimalIntegerLiterals

Tell us about your environment

• ESLint Version: 5.16.0
• Node Version: 10.16.0
• npm Version: 6.9.0

What parser (default, Babel-ESLint, etc.) are you using? default Please show your full configuration:

Configuration

module.exports = {
  parserOptions: {
    ecmaVersion: 2018,
  },
  rules: {
    'no-octal': 'error',
  },
};

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

let x;
x = 018;
x = 081;
x = 018.2;
x = 081.2;
x = 018e2;
x = 081e2;

eslint index.js

What did you expect to happen? By the specification both 018 and 081 are NonOctalDecimalIntegerLiteral, not LegacyOctalIntegerLiteral.

If the no-octal rule is supposed to catch these literals (which look like octal literals but are actually evaluated as decimal literals), then it should report all 6 as errors.

Otherwise, if the rule is supposed to catch only octal literals, then it should report zero errors, and perhaps a new rule could be added.

What actually happened? Please include the actual, raw output from ESLint. Only 018, 018.2 and 018e2 are reported as errors:

2:5 error Octal literals should not be used no-octal 4:5 error Octal literals should not be used no-octal 6:5 error Octal literals should not be used no-octal

✖ 3 problems (3 errors, 0 warnings)

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

[not-an-aardvark]

You’re right, I think this is just a bug in the rule. It doesn’t make sense that 018 would be reported while 081 would not.

[mdjermanovic]

It most likely wasn’t a bug when /^0[0-7]/ commit was made, at least by the then actual specifications. There is nothing that could match 018 or 081 in 5.1 spec, its annex or any older specs, so these literals were probably expected to be caught by the parser as invalid.

However, browsers did support them as decimal integers. There were attempts to remove this support, but some important sites/apps were broken, so they are eventually included in ES6 as NonOctalDecimalIntegerLiteral and /^0[0-7]/ became a bug.