eslint-plugin-jsdoc
                                
                                 eslint-plugin-jsdoc copied to clipboard
                                
                                    eslint-plugin-jsdoc copied to clipboard
                            
                            
                            
                        `jsdoc/check-param-names` should be fixable if order is wrong
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.
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 eslint --fix, e.g., eslint --fix --rule='jsdoc/check-param-names': [2, {fix: ["badParamOrder", "duplicateParams", "extraParams", "badParamNames"]}], perhaps with our own CLI to simplify a little, e.g., jsdoc-fix check-param-names -badParamOrder -duplicateParams -extraParams -badParamNames
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):
- badParamOrder - on
- duplicateParams - on ~(if argument count would match after removing dupe)~
- extraParams - off
- badParamNames - off