🔪 Deprecate no-loss-of-precision rule extension

[JoshuaKGoldberg]

Overview

https://typescript-eslint.io/rules/no-loss-of-precision states that it exists to add support for numeric separators to the base eslint/no-loss-of-precision rule. But, numeric separators have passed stage 3 and are natively supported in ESLint I believe. [Example ESLint playground with the rule working on a number with a numeric separator]

tl;dr: I propose we remove the rule extension because the base rule contains all its features.

👉 I'm not proposing we remove the base rule (or ask ESLint to)

Whether it exists in popular configs such as eslint-config-airbnb-typescript and eslint-config-standard-with-typescript

• eslint-config-airbnb-typescript: yes, https://github.com/iamturns/eslint-config-airbnb-typescript/blob/8ef77c928c97d977f053c9c638831363a715d4a9/lib/shared.js#L143
• eslint-config-standard-with-typescript: yes, https://github.com/standard/eslint-config-standard-with-typescript/blob/b7b298d13ec737684e4368c726a3a9a66cd2f465/src/index.ts#L16

Sourcegraph queries showing how often it appears in user configs

Sourcegraph query showing it used in <200 repos: this doesn't seem like a particularly common rule for users to explicitly specify. That makes sense to me given that it's in the base recommended config (and has been for a while).

[Josh-Cena]

Interesting—I would have expected this rule to handle numeric type literals!

const a: 9007199254740993 = 9007199254740992; // No error?

[That-Guy977]

@typescript-eslint/no-extra-semi states that it adds support for proposal-class-fields which is also stage 4 and is supported by the base rule as one of its examples.

I'm not familiar enough with the ecosystem here so I haven't made an issue for it, I wouldn't know what details to find and check 😅

[JoshuaKGoldberg]

Ah, the nice thing about no-extra-semi is that it's going to be a part of eslint.style now. So that's less for us to worry about. Good spot!

[JoshuaKGoldberg]

#8832 was merged into the v8 branch. ✅