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

Allow user to configure check-tag-names to report otherwise valid tag names (e.g., report @todo) #108

Closed
brettz9 opened this issue Nov 28, 2018 · 3 comments · Fixed by #302

Comments

@brettz9
Copy link
Collaborator

brettz9 commented Nov 28, 2018

If it is possible to tweak existing ESLint rules, it'd be great to have no-warning-comments optionally catch @todo style comments, and if not, it'd be nice to have a separate rule to do so.

Rather than limiting this to todo's, I figure check-tag-names could--when the tagNamePreference setting map had a tag set to false--report a normally valid tag. This would be useful, e.g., for reporting @todo. This would mirror how we do things in preferredTypes (it can also accept false).

Ideally, like preferredTypes, we could also allow message and replacement properties (along with template variables within the message), to allow a custom message (while still optionally allowing fixing, if a different tag were preferred), e.g., so that the ESLint error for "todo" could be something like "Please resolve to-dos or add to the tracker" or for preferring @extends over @augments: "@extends is preferred as it is more evocative of classes than @augments".

@brettz9 brettz9 changed the title Tweak ESLint no-warning-comments (or make new rule) to optionally do @todo check Allow user to configure check-tag-names to report otherwise valid tag names (e.g., report @todo) Jun 28, 2019
@brettz9
Copy link
Collaborator Author

brettz9 commented Jun 28, 2019

I've updated the original post here to make a more generic and reusable suggestion.

brettz9 added a commit to brettz9/eslint-plugin-jsdoc that referenced this issue Jun 30, 2019
…ixes gajus#108)

feat(check-tag-names): allow custom error messages when suggesting tags to replace (as with types in `check-types`)

Reporting normally valid tags may be of interest for tags like `@todo`. This is implemented by allowing the user to set targeted `tagNamePreference` tags to `false` or to an object with only a `message` and no `replacement`

Custom messages for `check-tag-names` are implemented by allowing the user to set  targeted `tagNamePreference` tags to an object with `message` and `replacement` (mirroring `preferredTypes` behavior). Note that for other rules leveraging `tagNamePreference` (via `utils.getPreferredTagName`) to find the user's preferred tag name, the `replacement` will be used in the likes of error messages but not the `message`.

Also, for various (param, return, and description-related) rules which have used `tagNamePreference` (via the `utils.getPreferredTagName` utility), report to user if they have blocked (probably inadvertently) and not indicated a replacement for the relevant tag needed by the rule in the `tagNamePreference` setting.
brettz9 added a commit to brettz9/eslint-plugin-jsdoc that referenced this issue Jun 30, 2019
…r providing custom error messages when suggesting tags to reject or replace (fixes gajus#108)

Reporting normally valid tags may be of interest for tags like `@todo`. This is implemented by allowing the user to set targeted `tagNamePreference` tags to `false` or to an object with only a `message` and no `replacement`

Custom messages for `check-tag-names` are implemented by allowing the user to set  targeted `tagNamePreference` tags to an object with `message` and `replacement` (mirroring `preferredTypes` behavior). Note that for other rules leveraging `tagNamePreference` (via `utils.getPreferredTagName`) to find the user's preferred tag name, the `replacement` will be used in the likes of error messages but not the `message`.

Also, for various (param, return, and description-related) rules which have used `tagNamePreference` (via the `utils.getPreferredTagName` utility), report to user if they have blocked (probably inadvertently) and not indicated a replacement for the relevant tag needed by the rule in the `tagNamePreference` setting.
brettz9 added a commit that referenced this issue Jul 5, 2019
…r messages when suggesting tags to reject or replace (#302)

* feat(check-tag-names): allow rejecting normally valid tag names and/or providing custom error messages when suggesting tags to reject or replace (fixes #108)

Reporting normally valid tags may be of interest for tags like `@todo`. This is implemented by allowing the user to set targeted `tagNamePreference` tags to `false` or to an object with only a `message` and no `replacement`

Custom messages for `check-tag-names` are implemented by allowing the user to set  targeted `tagNamePreference` tags to an object with `message` and `replacement` (mirroring `preferredTypes` behavior). Note that for other rules leveraging `tagNamePreference` (via `utils.getPreferredTagName`) to find the user's preferred tag name, the `replacement` will be used in the likes of error messages but not the `message`.

Also, for various (param, return, and description-related) rules which have used `tagNamePreference` (via the `utils.getPreferredTagName` utility), report to user if they have blocked (probably inadvertently) and not indicated a replacement for the relevant tag needed by the rule in the `tagNamePreference` setting.

Also, ensure `require-param-name` and `check-examples` report preferred tag name (not necessarily `param` or `example`, respectively) and err if `example` is a rejected tag
brettz9 added a commit that referenced this issue Jul 5, 2019
…r providing custom error messages when suggesting tags to reject or replace (fixes #108)

Reporting normally valid tags may be of interest for tags like `@todo`. This is implemented by allowing the user to set targeted `tagNamePreference` tags to `false` or to an object with only a `message` and no `replacement`

Custom messages for `check-tag-names` are implemented by allowing the user to set targeted `tagNamePreference` tags to an object with `message` and `replacement` (mirroring `preferredTypes` behavior). Note that for other rules leveraging `tagNamePreference` (via `utils.getPreferredTagName`) to find the user's preferred tag name, the `replacement` will be used in the likes of error messages but not the `message`.

Also, for various (param, return, and description-related) rules which have used `tagNamePreference` (via the `utils.getPreferredTagName` utility), report to user if they have blocked (probably inadvertently) and not indicated a replacement for the relevant tag needed by the rule in the `tagNamePreference` setting.

Also, ensure `require-param-name` and `check-examples` report preferred tag name (not necessarily `param` or `example`, respectively) and err if `example` is a rejected tag
@gajus
Copy link
Owner

gajus commented Jul 5, 2019

🎉 This issue has been resolved in version 10.3.0 🎉

The release is available on:

Your semantic-release bot 📦🚀

@gajus gajus added the released label Jul 5, 2019
brettz9 added a commit to brettz9/eslint-plugin-jsdoc that referenced this issue Jul 5, 2019
* master:
  feat(check-tag-names): allow rejecting normally valid tag names and/or providing custom error messages when suggesting tags to reject or replace (fixes gajus#108)
  Allow rejecting normally valid tag names and/or providing custom error messages when suggesting tags to reject or replace (gajus#302)

# Conflicts:
#	.README/README.md
#	README.md
#	src/iterateJsdoc.js
#	src/rules/checkTagNames.js
#	test/rules/assertions/checkTagNames.js
brettz9 added a commit to brettz9/eslint-plugin-jsdoc that referenced this issue Jul 5, 2019
…r providing custom error messages when suggesting tags to reject or replace (fixes gajus#108)

Reporting normally valid tags may be of interest for tags like `@todo`. This is implemented by allowing the user to set targeted `tagNamePreference` tags to `false` or to an object with only a `message` and no `replacement`

Custom messages for `check-tag-names` are implemented by allowing the user to set  targeted `tagNamePreference` tags to an object with `message` and `replacement` (mirroring `preferredTypes` behavior). Note that for other rules leveraging `tagNamePreference` (via `utils.getPreferredTagName`) to find the user's preferred tag name, the `replacement` will be used in the likes of error messages but not the `message`.

Also, for various (param, return, and description-related) rules which have used `tagNamePreference` (via the `utils.getPreferredTagName` utility), report to user if they have blocked (probably inadvertently) and not indicated a replacement for the relevant tag needed by the rule in the `tagNamePreference` setting.
brettz9 added a commit to interfaced/eslint-plugin-jsdoc that referenced this issue Jul 6, 2019
* master:
  feat(require-description-complete-sentence): validate explicit `description` tags
  fix(check-types): remove template substitution variables, `badType`, `preferredType`, and `replacement` (gajus#310)
  feat: remove `preferredTypesDefined` option in favor of making it apply automatically
  feat(check-tag-names): auto-allow tags in `tagNamePreference` setting to be defined; add `definedTags` option to replace `additionalTagNames.customTags` setting
  feat(check-tag-names): allow rejecting normally valid tag names and/or providing custom error messages when suggesting tags to reject or replace (fixes gajus#108)
  Allow rejecting normally valid tag names and/or providing custom error messages when suggesting tags to reject or replace (gajus#302)
  docs: indicate option defaults (fixes part of gajus#256) and ensure optioins all listed in docs
  chore: update Babel devDeps.
  feat(no-undefined-types): handle GCC generic functions
  docs: generate docs
  Add an invalid test case for incorrect @template type
  fix: reverse jsdoctypeparser update until traversal issue with "external:..." can be fixed
  feat: bump jsdoctypeparser to 5.0.0
  docs: generate docs
  Add support for generic functions in addition to classes
@gajus
Copy link
Owner

gajus commented Sep 1, 2019

🎉 This issue has been resolved in version 15.9.0 🎉

The release is available on:

Your semantic-release bot 📦🚀

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