New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
no-underscore-dangle to check function params #12579
Comments
This update will help users migrating from TSLint to ESLint to reach feature parity because the TSLint |
I would suggest this be configurable, as well, or, perhaps allow a single underscore in parameter names by default, given the common pattern of using |
I agree that this seems like an oversight of the rule and support this change. I do think it needs to be put behind an option to avoid a breaking change (maybe |
Is this still being evaluated? Or do we have a decision? |
I'll champion this. We still need support from two other team members before we can mark this as accepted. |
I would love to see that as well. We're migrating from TSLint and would really like to keep the consistency. Thanks! |
Marking this as accepted as there are 3 +1 from team members. I think |
…79) (#13545) * #12579 add allowFunctionParams option * #12579 edit doc & function name * #12579 add test case * #12579 add allowFunctionParam rule in docs * #12579 Update : test case when option is false * Return to origin code * Remove comments * Edit what was reviewed * Update: Destructuring param test * Update: invalid test case * Change initial state to true * #12579 Update: Edit what was reviewed * #12579 Fix a typo * #12579 Update : allow option * #12579 Update: Edit what was reviewed * #12579 Update : check type of param * #12579 Simplify the code * Update : test case * Fix : ...bar -> ..._bar
What rule do you want to change?
no-underscore-dangle
Does this change cause the rule to produce more or fewer warnings?
More warnings
How will the change be implemented? (New option, new default behavior, etc.)?
The updated rule will check if param Identifiers of FunctionDeclarations and ArrowFunctionExpressions have dangling underscores.
I suggest that underscore dangle in these situations is disallowed by default and can be configured using the same pattern as
"allowAfterThis"
and"allowAfterSuper"
.Please provide some example code that this change will affect:
What does the rule currently do for this code?
No error thrown.
What will the rule do after it's changed?
Throw an error because the function params have dangling underscores.
Are you willing to submit a pull request to implement this change?
Yes
The text was updated successfully, but these errors were encountered: