Allow rejecting normally valid tag names and/or providing custom error messages when suggesting tags to reject or replace #302
Conversation
…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
force-pushed
the
check-tag-names
branch
2 times, most recently
from
455b3ed to
5573eb5
Compare
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
|
Just for curiosity, what is your opinion on https://gist.github.com/stephenparish/9941e89d80e2bc58a153#format-of-the-commit-message
|
|
If I'm being fully frank on this, I dislike the terse commit message format, I hate the overly confining restrictions of the release notes not picking up multiple items in a commit, and I don't like such a restriction on length. I am not blind to the rationales used for these restrictions, but I personally find them very confining, as with the commit hooks which take time out to do testing and documentation when I have already tested locally (on top of the time it takes to push from my terrible internet service here), and I either forget to disable the commit hooks during testing, or if I get too used to disabling, I fear I will accidentally commit without letting them run. I think for people who can gather their thoughts all at once, without going through a few iterations as I inevitably do, these systems may work well, and I see their rationale for enforcing things on a team, but just personally speaking, I would never want to use this on my own projects, at least not without a lot of customization. But again, I understand their utility and rationale for enforcing some order out of chaos that developers otherwise might try to commit. |
* master: fix(check-types, no-undefined-types): add missing schemas for options
|
🎉 This PR is included in version 10.3.0 🎉 The release is available on: Your semantic-release bot 📦🚀 |
* 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
* 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
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 targetedtagNamePreferencetags tofalseor to an object with only amessageand noreplacementCustom messages for
check-tag-namesare implemented by allowing the user to set targetedtagNamePreferencetags to an object withmessageandreplacement(mirroringpreferredTypesbehavior). Note that for other rules leveragingtagNamePreference(viautils.getPreferredTagName) to find the user's preferred tag name, thereplacementwill be used in the likes of error messages but not themessage.Also, for various (param, return, and description-related) rules which have used
tagNamePreference(via theutils.getPreferredTagNameutility), report to user if they have blocked (probably inadvertently) and not indicated a replacement for the relevant tag needed by the rule in thetagNamePreferencesetting.