Thanks for the PR, @bradzacher!

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!

Name	Link
🔨 Latest commit	96e019c
🔍 Latest deploy log	https://app.netlify.com/sites/typescript-eslint/deploys/648d1262111e1c000823d6ba
😎 Deploy Preview	https://deploy-preview-6963--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.

☁️ Nx Cloud Report

CI is running/has finished running commands for commit 96e019c. 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.

@JoshuaKGoldberg / @armano2 I just pushed a new commit (178cf35) that further strictifies the types to a discriminated union.
This allows us to use types to validate that you don't provide mismatched properties.
This caught a bug in two of our schema defs:

• one of them defined additionalProperties instead of additionalItems
• one of them defined minLength instead of minItems

The downside to doing this is that you can be significantly less flexible in how you write schemas. For reference, you now must always define a type for each schema so that it can correctly pick the type, and it restricts some funky combos like adding anyOf + $ref + any concrete type.
Given that we always want to represent schemas as types - I don't think this is necessarily a bad thing though? Across our codebase we didn't end up changing anything aside from adding type in a few missing places.

If you guys think it's better to just stick to the spec and be loose - more than happy to revert the schema changes.

It's really hard to judge the impact of such a change, given that we don't know how all our consumers define schemas - but I'd think they're not too crazy?

Oof this hurts me though 😞. It seems like it'd be very annoying to have to write out the type when it can be inferred:

arrayOption: {
    type: 'string',
    enum: ['array', 'generic', 'array-simple'],
},

Maybe there's a happy medium we can go for? Only require type when it's not directly inferable?

It seems like it'd be very annoying to have to write out the type when it can be inferred

The flip side is that the explicit type will prevent cases like enum: [1, 2, "3"] that would otherwise make the 3rd option inaccessible.

Codecov Report

Merging #6963 (24a27af) into v6 (1366ae1) will increase coverage by 0.10%.
The diff coverage is 100.00%.

❗ Current head 24a27af differs from pull request most recent head 96e019c. Consider uploading reports for the commit 96e019c to get more accurate results

@@            Coverage Diff             @@
##               v6    #6963      +/-   ##
==========================================
+ Coverage   87.50%   87.61%   +0.10%     
==========================================
  Files         376      375       -1     
  Lines       12937    12923      -14     
  Branches     3821     3821              
==========================================
+ Hits        11321    11322       +1     
+ Misses       1231     1216      -15     
  Partials      385      385