-
-
Notifications
You must be signed in to change notification settings - Fork 163
jsdoc/check-param-names
should be fixable if order is wrong
#47
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
Comments
Also useful for path references |
PR is welcome. |
Duplicates could also be removed, extra items removed, and even bad names fixed, though any of these, especially the latter, could also be due to intending different params. Does anyone think any of these other cases should be fixable as well? |
If the function param in jsdoc is inconsistent to that in code, which one is considered truth? Which one should be fixed? |
The comments should be fixed, better to have documentation be updated rather than refactoring code. |
I'd think generally it'd be the code that was seen as truth, but yeah, that's the problem, it could be that the code isn't implemented as intended... And even for the cases of duplicates, a duplicate might indicate another param was intended, as with an extra param... But as @ProLoser suggests, there is a case for making it fixable in favor of the existing code too... |
While I think it would be better if ESLint had some way of passing in data from the command line to be used specifically for fixers (or formatters), we can leverage the fact that one can supply a specific rule with options at the command line, and create an option which tweaks the fixing behavior as desired. The option could be stored within one's config, or it could exclusively be used when one calls |
Fixing jsdoc makes more sense. Fixing code is too much work because the fixer needs to find and change all references of the param, and deal with name collision and shadowing. Also code is truth because it is what is being executed. |
Yeah, I think so. It could be added later as an option (along the lines I was describing) if someone cared to implement, as an alternative fix to the jsdoc approach. We only need to settle on one as the default. |
But the other cases are questionable as to applying by default, so while some might operate by default, others should be opt in. Here's what I'm thinking for default fixing (all favoring fixing jsdoc):
|
…xtra); partial fix for gajus#47
* master: feat: add fixer for no-types (gajus#350) fix(check-param-names): ensure polyfilling `Object.entries` for Node 6 fix(check-param-names): provide fixer duplicate param names (remove extra); partial fix for gajus#47 chore(npm): update deps (comment-parser, lodash) and devDep (husky, mocha) fix(require-param): reporting all missing jsdoc params (gajus#348) docs(check-examples): fix heading level docs(readme): remove section "Reference to jscs-jsdoc" chore: update Babel devDeps
I saw that another eslint plugin detects merely incorrect parameter order. It would be nice if this could be automatically fixed. You would have to ensure object properties are kept with param, and it could also (if this is preferred) move the
@returns
to the end.Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.
The text was updated successfully, but these errors were encountered: