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 onhttps://opencollective.com/typescript-eslint.

✅ Deploy Preview fortypescript-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 yourNetlify site settings.

☁️ Nx Cloud Report

CI is running/has finished running commands for commit96e019c. 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 💌 fromNxCloud.

@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 definedadditionalProperties instead ofadditionalItems
• one of them definedminLength instead ofminItems

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 atype for each schema so that it can correctly pick the type, and it restricts some funky combos like addinganyOf +$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 addingtype 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 thetype when it can be inferred:

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

Maybe there's a happy medium we can go for? Only requiretype 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 explicittype will prevent cases likeenum: [1, 2, "3"] that would otherwise make the 3rd option inaccessible.

Codecov Report

Merging#6963 (24a27af) intov6 (1366ae1) willincrease coverage by0.10%.
The diff coverage is100.00%.

❗ Current head24a27af differs from pull request most recent head96e019c. Consider uploading reports for the commit96e019c 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