Eslint-plugin-jsdoc: Missing fixers

[brettz9]

The following can have fixers added, with some fixers being by option only:

• [ ] check-examples (for rules that have fixers)
• [ ] check-indentation
• [ ] check-param-names (#47)
• [ ] check-syntax (add optional param brackets instead)
• [ ] implements-on-classes - Option to strip tag or change to @type
• [ ] match-description fixers? allow arbitrary
• [x] no-types (removes types)
• [ ] no-undefined-types (optionally auto-create typedef skeleton);
• [ ] require-description (fix the missing declaration if opted for "tag" option, i.e., insisting on @description)
• [ ] require-description-complete-sentence (optionally add period at end of previous line and per #337, add option to avoid triggering at all; make other fixing optional per #337 ).
• [x] require-example (fix the missing tag declaration)
• [x] require-jsdoc (adds an empty docblock)
• [ ] require-param-name (add the name/default for each jsdoc param and whether optional)
• [ ] require-param-type (optionally add curly brackets for each jsdoc param so one only need to add the type)
• [ ] require-param (add the tag; add name to docs if present in the signature)

(To facilitate such fixer work, we can use the new stringify method of https://github.com/yavorskiy/comment-parser/ which allows stringifying (modified) comment-parser JSON back to a string.)

As per #408 these fixers should apply recursively (as with existing ones).

[yeonjuan]

@brettz9 #396 - Adding fixer for require-param is done! plz check it. :)

[brettz9]

@yeonjuan : Would you mind submitting a PR with:

1. An additional test for fixing bar in the following:

         /**
           * @param foo
           * @param baz
           */
          function quux (foo, bar, baz) {
          }

1. Can we not get all params to be fixed in https://github.com/yeonjuan/eslint-plugin-jsdoc/blob/893916ce6e42c24309d27ac6b5eb71deb6014d5a/test/rules/assertions/requireParam.js#L32-L56 , https://github.com/yeonjuan/eslint-plugin-jsdoc/blob/893916ce6e42c24309d27ac6b5eb71deb6014d5a/test/rules/assertions/requireParam.js#L83-L106 and https://github.com/yeonjuan/eslint-plugin-jsdoc/blob/893916ce6e42c24309d27ac6b5eb71deb6014d5a/test/rules/assertions/requireParam.js#L136-L160

2. I'd also like to know what happens if there is a destructured param like:

          function quux (foo, {bar, baz}) {
          }

Lastly, while I wouldn't expect this now, particularly if we add destructuring support (#11), I just thought I'd mention here that it would be nice to have an option to auto-insert some configurable value like cfg or options:

          /**
           * @param foo
           * @param cfg
           * @param cfg.bar
           * @param cfg.baz
          */
          function quux (foo, {bar, baz}) {
          }

[brettz9]

I brought up in #404 the idea of our going forward to have the fixers apply all fixes in one go (as with that PR) despite eslint running multiple fix passes for us, with the reason being that the eslint testing framework only shows output with one fix applied.

While I can understand an argument for not changing code to suit testing quirks, I think it is advantageous in our case to do things this way, since our documentation is built on the tests, and I think we all agree we don't want to mislead users into which items are fixed or not.

And I am not aware of any advantages to expressing rules such that they can be used to make only one fix of a given problem.

Any thoughts on this, @gajus ?

[brettz9]

Another advantage of doing so for us would be that we should be more likely to catch recursive errors such as #403 .

[gajus]

@brettz9 Everything you said makes sense.

[yeonjuan]

@brettz9 👍 Nice! that's the point that I struggled - #404.