-
-
Notifications
You must be signed in to change notification settings - Fork 163
Allow user to configure check-tag-names
to report otherwise valid tag names (e.g., report @todo
)
#108
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
Labels
Comments
no-warning-comments
(or make new rule) to optionally do @todo
checkcheck-tag-names
to report otherwise valid tag names (e.g., report @todo
)
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
🎉 This issue has been resolved in version 10.3.0 🎉 The release is available on: Your semantic-release bot 📦🚀 |
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
🎉 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
If it is possible to tweak existing ESLint rules, it'd be great to haveno-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 thetagNamePreference
setting map had a tag set tofalse
--report a normally valid tag. This would be useful, e.g., for reporting@todo
. This would mirror how we do things inpreferredTypes
(it can also acceptfalse
).Ideally, like
preferredTypes
, we could also allowmessage
andreplacement
properties (along with template variables within themessage
), 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
".The text was updated successfully, but these errors were encountered: