Support numeric separators

[mdjermanovic]

Numeric separators proposal is now in Stage 4.

https://github.com/tc39/proposal-numeric-separator

ESLint's default parser will support this syntax under ecmaVersion: 2021

• Acorn: acornjs/acorn@e376a66
• Espree: Update: support logical assignment and numeric separators espree#448
• ESLint:
  • no-loss-of-precision Update: support numeric-separator in no-loss-of-precision (refs #13568) #13574
  • astUtils.isDecimalInteger and astUtils.isDecimalIntegerNumericToken Update: support numeric separators (refs #13568) #13581

[mdjermanovic]

I believe there's nothing more that should be updated in ESLint core and ESLint core rules, aside from those 2 items listed above.

It would be nice to also add some tests for quote-props and prefer-numeric-literals.

[anikethsaha]

I think for no-loss-of-precision only tests needs to be updated cause node.value will consist of non-numeric separated number and in no-loss-of-precision it is using node.value itself.

It needs to be updated, there are some places where it is using node.raw

[anikethsaha]

I can work on no-loss-of-precision if it's ok.

[mdjermanovic]

@anikethsaha

We usually prepare one big PR that covers all new features that are going to be supported by the next espree version, because all changes should be ideally merged and released at once, right after releasing espree.

I guess it would be easier to review and approve separate PRs, e.g., one per new language feature (like numeric separators), though they still can't be merged until the new espree is released, because of the github espree reference.

On the other hand, the downside of separate PRs is that we should take care to merge all of them for the same eslint version, even if they have conflicts.

In this particular case, we have three new features - numeric separator, logical assignment, and two new globals which require es2021 environment. At the first glance, it doesn't look there will be any conflicts between the three PRs.

@eslint/eslint-team thoughts about making three separate PRs?

[anikethsaha]

Thanks, @mdjermanovic for explaining, I missed to notice that even previous PRs were single PRs. My bad!

I would prefer the approach that would help the reviewers and fewer merge conflicts yeah for numeric separators I don't think there would be any conflicting change (at least for the rules ).

Maybe one more way can be to create a branch as numeric separators and separate PRs against numeric separators and then later numeric operators -> master. One drawback of this is more time-consuming. And benefits can be plus points for both separate and single big PR i.e easy to review and it will give a space to fix the merge conflicts (if any) before merging to master !

[kaicataldo]

I prefer smaller PRs, personally :) As long as folks aren't touching the same code, we should be able to release Espree and then bump the version in individual PRs. When they're all ready and approved, we can merge them in, rebasing the latter ones on the first.

[yeonjuan]

@mdjermanovic

thoughts about making three separate PRs?

Personally I prefer separate PR, cause it's easy to review and avoid conflicts

[nzakas]

I also prefer smaller PRs. Larger ones make conflicts more likely and so can be more difficult to get it merged. I’d actually prefer merging Espree changes first and then having a separate PR for each rule change.

[mdjermanovic]

Seems there's an agreement to split PRs.

I'm working on a PR for the rest of the changes related to numeric separators.

[mdjermanovic]

This is all merged and released, so closing.

[naoisegolden]

Anyone looking for the rule enforce or prefer numeric separators: I started a simple version here https://github.com/naoisegolden/eslint-plugin-prefer-numeric-separators, feel free to contribute.

[pustovalov]

Also you can try this rule: unicorn/numeric-separators-style