Chore: enable no-param-reassign on ESLint codebase #10065
Conversation
not-an-aardvark
force-pushed
the
enable-no-param-reassign
branch
from
d2fecc8
to
3845f11
Compare
| if (!errors[0].length) { | ||
| errors = [errors]; | ||
| if (Array.isArray(providedIndentType)) { | ||
| errors = Array.isArray(providedIndentType[0]) ? providedIndentType : [providedIndentType]; |
There was a problem hiding this comment.
providedIndentType can be [[]]? it seems to be string in comment.
There was a problem hiding this comment.
The function allows omitting the indentType, in which case the first argument gets used used as the errors.
expectedErrors("space", [[]]);
// is the same as
expectedErrors([[]]);There was a problem hiding this comment.
I see. Thanks for detailed explanation! 👍
| while (node) { | ||
| if (anyFunctionPattern.test(node.type)) { | ||
| return node; | ||
| for (let currentNode = node; currentNode; currentNode = currentNode.parent) { |
There was a problem hiding this comment.
This is completely personal preference, and can be ignored for this PR, but I don't like using for loops for something other then counters. It's unexpected, and makes it much harder to read the code.
|
@ilyavolodin Sorry about that. I personally think it's worth enabling the rule since there is usually a better option than reassigning a parameter, and IMO the rule helps in a vast majority of cases. However, I'd be fine with reverting if you feel strongly about not enabling the rule. It's also worth noting that we'll be able to use default parameters soon when we drop support for Node 4, which will make it easier to have default values without reassigning parameters. |
|
No, don't feel strongly enough about it. Just know that every time I enabled it in my code bases, I ended up creating a bunch of exceptions, which is annoying. |
eslint-deprecated
bot
added
the
archived due to age
What is the purpose of this pull request? (put an "X" next to item)
[x] Other, please explain:
What changes did you make? (Give an overview)
This enables the
no-param-reassignrule on the ESLint codebase.I think reassigning parameters generally makes code harder to read, because it's not possible to skip over a part of a function and assume that the parameter names still refer to the same objects. This is especially true since we require JSDoc comments in our codebase -- after reassigning a parameter, the JSDoc comment is generally inaccurate for the new assigned value.
Is there anything you'd like reviewers to focus on?
Nothing in particular