Rule suggestion: no-var (node)

[albinekb]

Referring to this rule.

Standard should read node version from the engines (more information) property in package.json, if the version supports const, no-var should be added to the list of rules.

Any thoughts?
Is there any reason to use var in node versions that support const and let?

[dcousens]

Would probably break wayyy to much. Although, I agree with the rule fundamentally.
Might be worth linking in #523

[albinekb]

Maybe....

Will standard never release a breaking version, where developers need to fix their code? 😏

I mean, there must be room to add rules that break some codebases to make standard stricter (and thus better)?

[dcousens]

#382 might be what you're after, but in the end, I write code for environments where let isn't defined, so this would stop me from using standard since my local node version is >6.0.0.

[albinekb]

Cool!
Yes but if your code supports environments where let isn't defined, you don't have engines in your package.json set to node 6? 💭

See https://docs.npmjs.com/files/package.json#engines

[dcousens]

Isn't engines only enforced if the user specifies engines-strict? Which is default off...

[feross]

@dcousens I believe that npm will still print a warning in that case.

Anyway, I don't think that magical behavior like changing rules based on engines field is the way to go.

Once let works in more environments (like 90% of browsers on CanIUse I think we can consider enabling it. There's definitely an argument to be made that var serves no purpose once let is pervasive. Also, this rule is automatically fixable.

[dcousens]

Agreed @feross, I'm just saying I don't think that time is now. Hopefully soon though :)

[feross]

Cool -- I'll close this issue for now since it's not actionable.

[ForsakenHarmony]

currently at 83%

[redbmk]

Up to 91.4% now

[LinusU]

@feross is it time? 😎

[feross]

Yep, I think it's time 👍

[harrysarson]

May I inquire about the status of this one?

[LinusU]

This is something that we want to get in, if you want to work on this I would start with compiling a list of all the repos that would break if we change this. If it's not too many, we can open a PR against eslint-config-standard and start sending PRs to upstream projects (e.g. as in this one)

You can get the list by cloning this repo, adding the rule to eslintrc.json, and running the tests.

[feross]

Anyone want to help start the process of opening PRs against repos that would break? I want to get this into standard v14

[sonicdoe]

I’d like to help with this 👍 I’ve opened standard/eslint-config-standard#152 to add no-var to the ESLint config and included a list of all failing repositories in the description.

[feross]

@sonicdoe Thanks for taking on this task! 💪