Thanks for the PR, @JoshuaKGoldberg!

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. As a thank you, your profile/company logo will be added to our main README which receives thousands of unique visitors per day.

☁️ Nx Cloud Report

CI is running/has finished running commands for commit eea220c. As they complete they will appear below. Click to see the status, the terminal output, and the build insights.

📂 See all runs for this branch

Sent with 💌 from NxCloud.

✅ Deploy Preview for typescript-eslint ready!

Name	Link
🔨 Latest commit	eea220c
🔍 Latest deploy log	https://app.netlify.com/sites/typescript-eslint/deploys/6363c413fa77db0008b0069b
😎 Deploy Preview	https://deploy-preview-5874--typescript-eslint.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify site settings.

Also, this seems to be focused on bug reports. Do feature requests have different accepting prs procedure?

Yeah this is based off of my docs and so far I had only covered bug report issues.

Feature requests are something along the lines of:

1. The request must be related to TS syntax, or propose a check that requires type information to be accurate.
   • This is for cases where people propose something like "I want to prevent people using arrow functions". Not TS-specific, nor does it need type-info -> doesn't belong in this project.
2. The request must be useful to the broader TS community (put another way - we as maintainers have to assess it as something a large portion of users might want to use [based on our experience]).
   • This is hard as it's kind-of subjective. Most of the time this exists to give us an out for when people request something like "my project uses this very specific style, can you make a rule to enforce it?"
   • I am generally really strict on this check when it comes to rule options. Rule options are very expensive to maintain (forks in code = double testing), so I always want a really solid and broadly usable proposal for an option.
3. The request should not fit into the purview of another popular plugin (eg eslint-plugin-import, eslint-plugin-jest, eslint-plugin-promises, ...)
   • We want to avoid stepping on other plugin's toes!
4. The request should be framework agnostic. We don't accept rules for react-specific features, or angular, jest, mocha, etc. There's plugins/projects for each of those specific things, and we are framework agnostic on purpose.
   • One caveat here is that we support what TS supports out of the box. I.e. TS supports JSX syntax, so we do to - but we don't support react semantics / types.

A lot of the checks here exist to ensure we're not just adding rules or options willy-nilly so that we can keep a lid on the maintenance burden of the project.

The TL;DR for the above constraints is just "there has to be a really good and broadly applicable TS-specific usecase for us to add an option or new rule".