[no-loss-of-precision] The rule reports false positives for values with numeric separators

[merlinnot]

Tell us about your environment

• ESLint Version: v7.1.0
• Node Version: v14.0.0
• npm Version: v6.14.4

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

@typescript-eslint/parser

Please show your full configuration:

It's in a public repository: https://github.com/ridedott/eslint-config

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

const x = 1_000;

eslint --cache --cache-location './.cache/eslint' --fix '**/*.ts'

What did you expect to happen?

I expected not to see a no-loss-of-precision issue reported for this number.

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

An issue is reported for this rule.

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

Yes, if the rule creator won't do it themself 🙂

[anikethsaha]

I think it should be reported in typescript-eslint repo ?

cause numeric-separator is still in Stage 3 and eslint doesnt support stage 3 proposal .

also, the compiled JS for this TS code is working fine with eslint

[kaicataldo]

As @anikethsaha mentions above, this is still currently experimental syntax. We will add support for this syntax in core rules once it reaches stage 4.

[merlinnot]

Thanks, I'll be waiting for it :)

[bricss]

Hi everyone,

I hit this issue today as well, and it's potential problem in here. 🙂

Fan fact, is that Numeric separators are broadly used in many projects and supported already by ALL modern browsers and node as well, for about of one year.

At the moment, it's impossible to use this new rule in any project that's already use separators in codebase.

It should be at least a way, to add an option to this rule to allow the character / code to be specified in numbers. 🤠

[kaicataldo]

While we can't implement support until this reaches stage 4, it might be worth checking out babel-eslint to see if that allows you to lint this syntax.

[bricss]

I have checked rule with babel-eslint and can confirm, that there is no luck. It still failing for every number with _ in it. 😥

[mdjermanovic]

I have checked rule with babel-eslint and can confirm, that there is no luck. It still failing for every number with _ in it.

The core no-loss-of-precision rule will not work well with numeric separators until that syntax reaches stage 4 and we update the rule, regardless of the parser being used.

In the meantime, if you're using @typescript-eslint/parser, they have already implemented @typescript-eslint/no-loss-of-precision rule which extends the core rule and works well with numeric separators.

If you're using babel-eslint parser, you could ask eslint-plugin-babel to extend the core rule in a similar way.

[eslint-deprecated]

Unfortunately, it looks like there wasn't enough interest from the team
or community to implement this change. While we wish we'd be able to
accommodate everyone's requests, we do need to prioritize. We've found
that issues failing to reach accepted status after 21 days tend to
never be accepted, and as such, we close those issues.
This doesn't mean the idea isn't interesting or useful, just that it's
not something the team can commit to.

Thanks for contributing to ESLint and we appreciate your understanding.

[mdjermanovic]

Numeric separators are stage 4 now.

#13568 tracks everything that should be updated to support this syntax, and that includes no-loss-of-precision rule.

[mdjermanovic]

Fixed by #13574, ESLint v7.8.0