docs(eslint-plugin): [ban-ts-comment] fix wording of directive option descriptions#12467
Conversation
…nd ts-nocheck directives
|
Thanks for the PR, @zaewc! typescript-eslint is a 100% community driven project, and we are incredibly grateful that you are contributing to that community. The core maintainers work on this in their personal time, so please understand that it may not be possible for them to review your work immediately. Thanks again! 🙏 Please, if you or your company is finding typescript-eslint valuable, help us sustain the project by sponsoring it transparently on https://opencollective.com/typescript-eslint. |
✅ Deploy Preview for typescript-eslint ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
|
View your CI Pipeline Execution ↗ for commit 07a5f2b
💡 Verify your cache is correct by running tasks in a sandbox. Read docs ↗ ☁️ Nx Cloud last updated this comment at |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #12467 +/- ##
==========================================
+ Coverage 87.06% 94.74% +7.68%
==========================================
Files 514 223 -291
Lines 16616 11426 -5190
Branches 5193 3809 -1384
==========================================
- Hits 14467 10826 -3641
+ Misses 1461 255 -1206
+ Partials 688 345 -343
Flags with carried forward coverage won't be shown. Click here to find out more.
🚀 New features to boost your workflow:
|
JoshuaKGoldberg
left a comment
There was a problem hiding this comment.
Yup, LGTM!
@zaewc I appreciate the attention to describing your changes, but there's no need to list out long PR bodies with tables of changes for something that changes a few words each in 4 docs lines 🙂. We touch on this in https://typescript-eslint.io/contributing/ai-policy - we're swamped by AI slop now, so anything you can do to trim that down would be much appreciated.
Thanks, that makes sense, sorry for the overly long Overview |
PR Checklist
Overview
Fixes the schema
descriptionwording for the directive options ofban-ts-comment, which are surfaced both in the auto-generated Options section of the rule's docs page and as tooltips in editor autocompleteThe
ts-expect-errordescription was broken in two ways:allowwas missing ("Whether and when expect-error directives, …"isn't a grammatical sentence), andts-prefix was missing (expect-errorinstead ofts-expect-error), unlike its three siblingsPer @kirkwaiblinger's review note on the issue, I fixed the ungrammatical
"Whether allow …"on the other three options at the same time so all 4 are now consistent and grammatical:ts-checkWhether allow ts-check directives, and with which restrictions.Whether to allow ts-check directives, and with which restrictions.ts-expect-errorWhether and when expect-error directives, and with which restrictions.Whether to allow ts-expect-error directives, and with which restrictions.ts-ignoreWhether allow ts-ignore directives, and with which restrictions.Whether to allow ts-ignore directives, and with which restrictions.ts-nocheckWhether allow ts-nocheck directives, and with which restrictions.Whether to allow ts-nocheck directives, and with which restrictions.The
ban-ts-commentschema snapshot was regenerated (vitest -u) to match; the docs page's Options section is generated from the schema at build time, so no static docs file needed editing