feat(eslint-plugin): [consistent-type-assertions] add arrayLiteralTypeAssertions options

[yeonjuan]

PR Checklist

• Addresses an existing open issue: fixes Enhancement: [consistent-type-assertions] Prefer type annotation over assertion for arrays #6374
• That issue was marked as accepting prs
• Steps in Contributing were taken

Overview

This pr addresses #6374 and adds arrayLiteralTypeAssertions option to the consistent-type-assertions rule.
It starts from #6749, which was previously closed, and adds allow-as-parameter to the arrayLiteralTypeAssertions option. (#6749 (comment))

Co-authored-by: @danvk

[typescript-eslint]

Thanks for the PR, @yeonjuan!

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	b64df60
🔍 Latest deploy log	https://app.netlify.com/sites/typescript-eslint/deploys/677380a8ca061e00080b8cc6
😎 Deploy Preview	https://deploy-preview-10565--typescript-eslint.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.
Lighthouse	1 paths audited Performance: 93 (🟢 up 2 from production) Accessibility: 100 (no change from production) Best Practices: 92 (no change from production) SEO: 98 (no change from production) PWA: 80 (no change from production) View the detailed breakdown and full score reports

---

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

[nx-cloud]

View your CI Pipeline Execution ↗ for commit b64df60.

Command	Status	Duration	Result
nx test eslint-plugin --coverage=false	✅ Succeeded	7m 17s	View ↗
nx test eslint-plugin	✅ Succeeded	5m 56s	View ↗
nx test type-utils --coverage=false	✅ Succeeded	<1s	View ↗
nx test visitor-keys --coverage=false	✅ Succeeded	<1s	View ↗
nx test rule-tester --coverage=false	✅ Succeeded	<1s	View ↗
nx test typescript-estree --coverage=false	✅ Succeeded	<1s	View ↗
nx run types:build	✅ Succeeded	<1s	View ↗
nx test utils --coverage=false	✅ Succeeded	<1s	View ↗
Additional runs (24)	✅ Succeeded	...	View ↗

---

☁️ Nx Cloud last updated this comment at 2024-12-31 05:42:15 UTC

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 86.92%. Comparing base (3ae4148) to head (b64df60).
Report is 8 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #10565      +/-   ##
==========================================
+ Coverage   86.86%   86.92%   +0.05%     
==========================================
  Files         445      446       +1     
  Lines       15455    15521      +66     
  Branches     4507     4524      +17     
==========================================
+ Hits        13425    13491      +66     
  Misses       1675     1675              
  Partials      355      355              

Flag	Coverage Δ
unittest	86.92% <100.00%> (+0.05%)	⬆️

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

Files with missing lines	Coverage Δ
...int-plugin/src/rules/consistent-type-assertions.ts	95.89% <100.00%> (+1.06%)	⬆️

... and 10 files with indirect coverage changes

[JoshuaKGoldberg]

Lovely! The logic all makes sense and I like how the array and object checks are now mirrored. Great.

Requesting changes on some docs and testing please. 🚀

[JoshuaKGoldberg]

😬 I know this is existing code with its own pattern, but - we're trying to move away from auto-generated tests. They're much harder to statically analyze and tend to batch together a lot of redundant tests with multiple edge cases per test. Could you please keep to manually written tests for the new code?

Since all this change does functionally is add a new typed of checked assertion (arrays), I think adding a test per each of these lines should be fine.

[yeonjuan]

Sounds good,

I think adding a test per each of these lines should be fine.

Does this mean writing a test like the one below?

    {
      code: `
const x = [] as string[];
const x = ['a'] as string[];
const x = [] as Array<string>;
const x = ['a'] as Array<string>;
const x = [Math.random() ? 'a' : 'b'] as 'a'[];
      `, options: [
        {
          assertionStyle: "as"
        }
      ]
    }