Skip to content
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

Missing fixers #336

Open
3 of 16 tasks
brettz9 opened this issue Jul 13, 2019 · 9 comments
Open
3 of 16 tasks

Missing fixers #336

brettz9 opened this issue Jul 13, 2019 · 9 comments

Comments

@brettz9
Copy link
Collaborator

brettz9 commented Jul 13, 2019

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 (jsdoc/check-param-names should be fixable if order is wrong #47)
  • check-syntax (add optional param brackets instead)
  • implements-on-classes - Option to strip tag or change to @type
  • match-description fixers? allow arbitrary
  • 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 require-description-complete-sentence false positives #337, add option to avoid triggering at all; make other fixing optional per require-description-complete-sentence false positives #337 ).
  • require-example (fix the missing tag declaration)
  • 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)
  • require-returns

(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).


Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

brettz9 pushed a commit that referenced this issue Jul 21, 2019
feat(no-types): add fixer; partial fix for #336 (#350)
brettz9 added a commit to brettz9/eslint-plugin-jsdoc that referenced this issue Jul 22, 2019
…o nothing with missing description); fixes part of gajus#336
l1bbcsg pushed a commit to interfaced/eslint-plugin-jsdoc that referenced this issue Aug 8, 2019
…o nothing with missing description); fixes part of gajus#336
@yeonjuan
Copy link
Contributor

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

@brettz9
Copy link
Collaborator Author

brettz9 commented Oct 11, 2019

@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
Copy link
Collaborator Author

brettz9 commented Oct 18, 2019

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
Copy link
Collaborator Author

brettz9 commented Oct 18, 2019

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

@gajus
Copy link
Owner

gajus commented Oct 18, 2019

@brettz9 Everything you said makes sense.

@yeonjuan
Copy link
Contributor

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

@brettz9
Copy link
Collaborator Author

brettz9 commented Jul 15, 2021

For cases where multiple types of fixing may be desirable, we can use "suggestions": https://eslint.org/docs/developer-guide/working-with-rules#providing-suggestions

@vlafranca
Copy link

I think the require-returns fixer is not also missing, is it possible to add it to the list ? Or am I mistaken ?

@brettz9
Copy link
Collaborator Author

brettz9 commented Aug 22, 2023

@vlafranca : Added, thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants