Rule Change: There should be a way to specify ignores for no-param-reassign
See original GitHub issueWhat rule do you want to change?
no-param-reassign
What change to do you want to make?
Generate fewer warnings
How do you think the change should be implemented?
A new option
Example code
function myWidget(spec) {
spec ||= {};
...
}
What does the rule currently do for this code?
Report that spec
is reassigned.
What will the rule do after it’s changed?
With {ignore: ["spec"]}
, the rule should stop reporting reassignments to spec
.
Participation
- I am willing to submit a pull request to implement this change.
Additional comments
No response
Issue Analytics
- State:
- Created a year ago
- Comments:7 (7 by maintainers)
Top Results From Across the Web
Usage with eslint no-param-reassign · Issue #189 - GitHub
So draftState could be ignored. But that would only exclude that name. Is there a better way without disabling that rule?
Read more >no-param-reassign - ESLint - Pluggable JavaScript Linter
This rule takes one option, an object, with a boolean property "props" , and arrays "ignorePropertyModificationsFor" and "ignorePropertyModificationsForRegex" .
Read more >How to avoid no-param-reassign when setting a property on a ...
This way rule is still active but it will not warn for properties. ... list" of object names with respect to which parameter...
Read more >Lint - Ant Design Pro
Although it exists in dependencies, but require.resolve cannot be obtained, this rule changes from warning to error. Ignore ['^ @ /', '^ @@...
Read more >Configuring ESLint - Breword 文档集合
There are two primary ways to configure ESLint: ... To change a rule setting, you must set the rule ID equal to one...
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 Free
Top 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
There are tools to wrap and extend existing rules, like eslint-rule-composer and eslint-rule-extender, but note that rule definitions are not public API and therefore can change and possibly break extension rules in non-major versions. Copy & paste & edit is actually the recommended way.
Sorry for the delay.
I’m not in favor of adding this option to the core rule because I think there should be no reason to allow exceptions by param names in a new codebase. In particular, it would be confusing why the option exists and could lead to logic errors in the code, as in https://github.com/eslint/eslint/issues/15244. For specific use cases, such as an existing codebase that follows a certain pattern, it’s always possible to create a custom rule based on the core rule.