Rule proposal: no-implicit-coercion using a negative/minus (-) symbol

[NotWoods]

Before You File a Proposal Please Confirm You Have Done The Following...

• I have searched for related issues and found none that match my proposal.
• I have searched the current rule list and found no rules that match my proposal.
• I have read the FAQ and my problem is not listed.

My proposal is suitable for this project

• My proposal specifically checks TypeScript syntax, or it proposes a check that requires type information to be accurate.
• My proposal is not a "formatting rule"; meaning it does not just enforce how code is formatted (whitespace, brace placement, etc).
• I believe my proposal would be useful to the broader TypeScript community (meaning it is not a niche proposal).

Description

ESLint's no-implicit-coercion rule can't check for casting a string to a number by using - because it would disallow negating a regular number. By using type information, we can provide additional coercion checks.

Fail Cases

const foo = '32px'
var n = -foo;

Pass Cases

const bar = 32
var n = -bar;
var n = -Number(foo);
var n = -parseFloat(foo);
var n = -parseInt(foo, 10);

Additional Info

No response

[bradzacher]

This is a really interesting idea.
I'll be honest when I say that it's been a very long time since I've had to operate on numbers and needed to use the unary - to invert a sign.
I'd almost go as far as to ban it for non-literal numbers altogether (if you want to invert then use * -1 which will be correctly checked by TS).

But this does seem like a niche, but useful check to have to ensure safety.

[NotWoods]

It might be worthwhile for the documentation for this rule to show how to configure no-restricted-syntax to ban - altogether.

[samestep]

I've created an ESLint plugin with this rule: https://www.npmjs.com/package/eslint-plugin-unary-minus

[tylerlaprade]

Thank you @samestep, looks good! Any reason not to submit it as a PR to the main repo?

[samestep]

Thanks @tylerlaprade! The only reason was this conversation I had on Discord with @Zamiell yesterday:

start by making your own custom rule yeah
and then get everything working and write some tests, then you can submit a PR afterward

Should I submit a PR with this now? How can I do that?

[bradzacher]

Yeah there is no need to publish a separate package for a rule! Doing that involves a lot of extra boilerplate and effort - we don't recommend doing that unless you've got an idea for a rule that we haven't marked as accepted.

Even if you want to try the rule locally on your project before submitting a PR we suggest local linking for that to save you time!

To submit your rule for us you'll just need to fork and clone the repo and then add your code to our plugin, then raise a PR. The pain here will be in adjusting your code and tests to adhere to our code style but should otherwise be straight-forward.

[samestep]

Oh! Sorry about that, I guess I just misunderstood @Zamiell's message on Discord.