feat: fork json schema types for better compat with ESLint rule validation

[bradzacher]

BREAKING CHANGE:
@typescript-eslint/utils now only exports the v4 JSON schema types - the only version ESLint validates rules with.
Removed the unsafe [string]: any indexer from the JSONSchema4 type to help ensure invalid properties aren't used.

---

This was something I noticed whilst working on our schema enhancements - we re-exported all these types that were mostly useless for lint rules because ESLint is hard-locked to v4 of the schema. So I decided to remove those newer schema types from the export.

I was going to leave it there, but then I remember that I had added a local patch that strictified the types by removing the unsafe indexer (which helped us catch bugs in our schemas). So I decided we can just fork the types entirely and apply my patch so all consumers get that same benefit.

[typescript-eslint]

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.

[netlify]

✅ 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]

☁️ 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

---

✅ Successfully ran 31 targets

• Node 16 - nx test eslint-plugin --coverage=false
• Node 20 - nx test eslint-plugin
• nx run-many --target=lint --parallel
• Node 20 - nx test typescript-estree
• Node 20 - nx test visitor-keys
• Node 20 - nx run types:build
• Node 20 - nx test utils
• Node 20 - nx test scope-manager
• Node 20 - nx test type-utils
• Node 20 - nx test rule-schema-to-typescript-types
• Node 20 - nx test eslint-plugin-tslint
• Node 16 - nx test typescript-estree --coverage=false
• Node 20 - nx test parser
• Node 20 - nx test repo-tools
• Node 20 - nx test eslint-plugin-internal
• Node 20 - nx test ast-spec
• Node 16 - nx test scope-manager --coverage=false
• Node 16 - nx test type-utils --coverage=false
• Node 16 - nx test utils --coverage=false
• Node 16 - nx test visitor-keys --coverage=false
• Node 16 - nx run types:build
• nx run-many --target=typecheck --parallel
• Node 16 - nx test parser --coverage=false
• Node 16 - nx test rule-schema-to-typescript-types --coverage=false
• Node 16 - nx test repo-tools --coverage=false
• Node 16 - nx test eslint-plugin-tslint --coverage=false
• Node 16 - nx test eslint-plugin-internal --coverage=false
• nx run integration-tests:test
• Node 16 - nx test ast-spec --coverage=false
• nx run types:build
• nx run-many --target=build --parallel --exclude=website --exclude=website-eslint

---

Sent with 💌 from NxCloud.

[JoshuaKGoldberg]

🔥 looks great! I wonder if we could export this as our own types so other ESLint projects (maybe ESLint itself, if they want a devDependency to help with types) could use it? Given that it's already exported by @typescript-eslint/utils I think it's fine to stay as-is.

[bradzacher]

@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?

[JoshuaKGoldberg]

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?

[bradzacher]

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]

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

Additional details and impacted files

@@            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              

Flag	Coverage Δ
unittest	87.61% <100.00%> (+0.10%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
packages/eslint-plugin/src/rules/array-type.ts	97.14% <ø> (ø)
packages/eslint-plugin/src/rules/ban-ts-comment.ts	96.96% <ø> (ø)
...t-plugin/src/rules/class-literal-property-style.ts	100.00% <ø> (ø)
packages/eslint-plugin/src/rules/comma-dangle.ts	93.33% <ø> (ø)
...lugin/src/rules/consistent-generic-constructors.ts	90.69% <ø> (ø)
...lugin/src/rules/consistent-indexed-object-style.ts	92.06% <ø> (ø)
...int-plugin/src/rules/consistent-type-assertions.ts	92.59% <ø> (ø)
...nt-plugin/src/rules/consistent-type-definitions.ts	97.29% <ø> (ø)
...eslint-plugin/src/rules/consistent-type-imports.ts	94.50% <ø> (ø)
...-plugin/src/rules/explicit-member-accessibility.ts	96.10% <ø> (-0.05%)	⬇️
... and 33 more

... and 7 files with indirect coverage changes