New rule proposal: no-undef-default
See original GitHub issuePlease describe what the rule should do:
Disallows using global undefined
as a default value in destructuring patterns.
Optionally, disallows the same for function parameters.
Has autofix for both (with some exceptions for params).
What category of rule is this? (place an “X” next to just one item)
[X] Suggests an alternate way of doing something (suggestion)
Provide 2-3 code examples that this rule will warn about:
Destructuring:
/* eslint no-undef-default: ["error"]*/
var { a = undefined } = foo;
let { bar: b = undefined } = foo;
const [c = undefined] = foo;
({ d = undefined } = foo);
[e = undefined] = foo;
Auto-fixed to:
/* eslint no-undef-default: ["error"]*/
var { a } = foo;
let { bar: b } = foo;
const [c] = foo;
({ d } = foo);
[e] = foo;
Function params:
/* eslint no-undef-default: ["error", { enforceForParams: true }]*/
function foo(a, b = undefined, c = undefined) {
}
const bar = (d, e = 1, f = undefined) => {
}
Auto-fixed to:
/* eslint no-undef-default: ["error", { enforceForParams: true }]*/
function foo(a, b = undefined, c) { // just warning without autofix for `b`
}
const bar = (d, e = 1, f) => {
}
Autofix never removes a param default when it’s the first default in the list because it would automatically change function’s length
. Also, it could turn a non-simple param list into a simple param list, I’m not sure could that also change some behavior.
Why should this rule be included in ESLint (instead of a plugin)?
It’s a best practice to avoid unnecessary use of undefined
, and it’s completely unnecessary in destructuring patterns. Removing undefined
improves readability and understanding on how destructuring works.
It could be used in functions to control length
, that’s why it’s behind an option (default is false
).
There is already a similar rule, no-undef-init
.
I’m not sure about the name, should it be no-undef-default
or no-undef-defaults
.
Are you willing to submit a pull request to implement this rule?
Yes.
Issue Analytics
- State:
- Created 4 years ago
- Reactions:2
- Comments:7 (7 by maintainers)
Top GitHub Comments
Not sure this rises to the level of inclusion into the core. I haven’t seen a code like that before. While I think the rule is valid, it seems to me that it only covers an extreme edge case.
What a really unfortunate decision 😕