Thanks for the PR, @G-Rath!

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.

Codecov Report

Merging #1433 into master will increase coverage by 0.06%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master    #1433      +/-   ##
==========================================
+ Coverage   94.48%   94.55%   +0.06%     
==========================================
  Files         142      142              
  Lines        6077     6076       -1     
  Branches     1726     1726              
==========================================
+ Hits         5742     5745       +3     
+ Misses        182      180       -2     
+ Partials      153      151       -2

@G-Rath you don't have force push commits as we always squash changes before merging (all other merge methods are disabled in this repo)

(this helps with tracking what review comments was addressed in commit)

@armano2 cheers for the reminder - I've been bouncing between a bunch of OSS repos, so my brains been autopiloting a bit 😂

Thanks btw for the very good example of PM vs AM - I completely didn't think of it.

Thanks for submitting this, but this rule is about to be deprecated.
See #1318, the new rule will handle cases like this in a much nicer fashion.

@bradzacher we do not know when #1318 will be ready, and this one can be good enough as temp fix while ppl are waiting.

#1318 is ready, I just need to fix up the recommended config tests/generator so that it doesn't remove deprecated rules.
I was planning on having it in with the next release.

naming-convention is released, so I'm going to close this.
thanks for the contribution!

@bradzacher hate to bother you with this, but would you be able to help me form a regex using naming-convention that allows IAM but not I[A-Z]?

The example you provided in the original PR works perfectly as a replacement for interface-name-prefix:

  { selector: "interface", format: ["PascalCase"], custom: { regex: "^I[A-Z]", match: false } },

But I can't come up with a regex that doesn't match IAM but still matches other I prefixes.

(I'm having trouble in general figuring out how to make exclusions work, such as to allow child_process, but I'll probably make a proper issue to track that).

For reference; the interface-name-prefix rule didn't work in this case either:

You could go with a more complex regex to support multiple cases. This will work if your node version supports negative look-behinds.

/^([A-Z](?<!I)\w+|I[A-Z]+)$/

   [A-Z](?<!I)\w+
   ^^^^^^^^^^^^^^ use a negative look-behind to ban I prefix

                  I[A-Z]+
                  ^^^^^^^ match I followed by all caps (IAM)

Make sure match: true if you use that regex.

https://regexr.com/4sjvl

For reference; the interface-name-prefix rule didn't work in this case either:

Which is why I made this PR :)

/^(A-Z\w+|I[A-Z]+)$/

Amazing thanks!

I had a feeling negative look-behinds would be the case - playing around with that regexp, to me it seems like that might actually be the The Right One for that rule? (not that it matters since it's deprecated) - I can't think of a combo that generates a false positive.

Might be worth sticking somewhere - maybe a block under the deprecation notice for interface-name-prefix saying something like "you can achieve the desired behavior using this "?

Regardless, thanks again 😄