Brett Zamir

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

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

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

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

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

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

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

Is this promoting an anti-pattern though? With "typescript" `mode`, one can use `import()` with the type (keeping it within the jsdoc), and for discovery of defined types, I think #99...

As per https://github.com/gajus/eslint-plugin-jsdoc/issues/721#issuecomment-837929396 , I think the argument here is for consistency rather than endorsing the practice.

Excellent! Feel free to submit your tool to [awesome-jsdoc](https://github.com/brettz9/awesome-jsdoc) and [awesome-eslint](https://github.com/dustinspecker/awesome-eslint) and/or submit as a PR to `eslint-plugin-jsdoc`. If not the latter, feel free to close the issue. Thanks for...