no-useless-undefined - should not be fixable
See original GitHub issueAs it stands, the rule corrects console.log(undefined)
to console.log()
. These have different runtime behaviour, so it isn’t safe to autofix. The fixer should be downgraded to a suggestion.
Issue Analytics
- State:
- Created 3 years ago
- Reactions:1
- Comments:17 (9 by maintainers)
Top Results From Across the Web
eslint-plugin-unicorn/no-useless-undefined.md at main - GitHub
Disallow useless undefined. This rule is enabled in the ✓ recommended config. This rule is automatically fixable by the --fix CLI option.
Read more >undefined vs null in React state: Unicorn ESLint plugin no ...
undefined is not usable and indicates a condition that is most likely not what the programmer expected - hence it throws rather than...
Read more >eslint-plugin-unicorn/readme.md - UNPKG
- [no-unused-properties](docs/rules/no-unused-properties.md) - Disallow unused object properties. 131, - [no-useless-undefined](docs/rules/no-useless-undefined ...
Read more >Conflict no-useless-undefined with consistent-return #1199
When I enable the eslint-plugin-unicorn/no-useless-undefined rule, and have consistent-return rule enabled too the following code gives one violation in the ...
Read more >no-useless-call - ESLint - Pluggable JavaScript Linter
When Not To Use It ... If you don't want to be notified about unnecessary .call() and .apply() , you can safely disable...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
Fair enough - I suppose there is a threshold of what an edge case is. Relevant xkcd:
I still think this rule is making too many assumptions about the runtime implementation of the function. It relies on the function being called not doing something strange, which to me is dangerous.
Fair enough that we can’t expect to succeed in never making runtime behaviour changes. But in this case, I think there’s a pretty reasonable chance that automatically deleting a parameter will have a real side-effect.
Which is related to another reason this shouldn’t auto-fix IMO: unlike most autofix rules like
prettier/prettier
,indent
,no-semi
, etc., if I writedoSomething(undefined)
, it’s fairly likely that I did it on purpose, specifically because I didn’t wantdoSomething()
for whatever reason. The rule is autofixing to the more obvious overload. The fact that I wrotedoSomething(undefined)
is a signal thatdoSomething
is a weird function that behaves differently based on the number of args - at least the probability is much higher than for the average function call.So while it’s an edge case for the set of all function calls that
undefined
is “useful”, when this rule is actually triggered, it’s much more likely to be significant. It’s a good thing that the linter is flagging unusual and potentially dangerous code, but it’s a bad thing that it’s blindly fixing it, potentially without the developer noticing. In my case, I updated this package in a medium sized repo, and there were a bunch of lint changes. Included were a small number of false positive fixes for this rule that got silently changed byyarn lint --fix
. They might have slipped in unnoticed if there wasn’t proper test coverage. I would have preferred to handle them manually, since then I could have given proper thought to whether some refactoring/redesign was needed.Anyway, I’ll shut up now - it’s not that big a deal 🙃