Skip to content

test(eslint-plugin): adjust tests to verify no-unnecessary-type-assertion doesn't report template literals with expressions #10671

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Merged
merged 2 commits into from
Jan 20, 2025
Merged

test(eslint-plugin): adjust tests to verify no-unnecessary-type-assertion doesn't report template literals with expressions #10671

merged 2 commits into from
Jan 20, 2025

Conversation

ronami
Copy link
Member

@ronami ronami commented Jan 17, 2025 •
edited
Loading

PR Checklist

Overview

I've noticed this while reviewing #10618.

To my understanding, these tests should make sure the rule doesn't report on template literals with expressions.

It seems that even if this check is removed, these tests still pass. I think it's related to "fresh literals" (more on this here), as is shown below (playground link):

const foo = 'foo';

// the `hello ${foo}` expression does count as a literal
const test1 = `hello ${foo}` as const;
//      ^?

let bar = 'bar';

// the `hello ${bar}` expression doesn't count as a literal
// as it's inferred as `hello ${string}`
const test2 = `hello ${bar}` as const;
//      ^?

The expression coming from a widened let variable doesn't count as a literal, and it falls back to being checked as a non-literal (which always allows as const assertions).

This PR adjusts the tests to fail if this check is removed or changed incorrectly (this seems correct according to the original issue).

@typescript-eslint
Copy link
Contributor

Thanks for the PR, @ronami!

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 Netlify
Copy link

netlify bot commented Jan 17, 2025 •
edited
Loading

✅ Deploy Preview for typescript-eslint ready!

Name Link
🔨 Latest commit 27ba6f7
🔍 Latest deploy log https://app.netlify.com/sites/typescript-eslint/deploys/678d5f3ef9e6a000087344dd
😎 Deploy Preview https://deploy-preview-10671--typescript-eslint.netlify.app
📱 Preview on mobile
Toggle QR Code...

QR Code

Use your smartphone camera to open QR code link.
Lighthouse
Lighthouse		 1 paths audited
Performance: 99 (🟢 up 1 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 Nx Cloud
Copy link

nx-cloud bot commented Jan 17, 2025 •
edited
Loading

View your CI Pipeline Execution ↗ for commit 27ba6f7.

Command Status Duration Result
nx run-many --target=build --exclude website --... ✅ Succeeded 3s View ↗
nx run-many --target=clean ✅ Succeeded 10s View ↗

☁️ Nx Cloud last updated this comment at 2025-01-20 09:31:54 UTC

@ronami ronami changed the title test(eslint-plugin): adjust tests to verify no-unnecessary-type-assertion doesn't throw on template literals with expressions test(eslint-plugin): adjust tests to verify no-unnecessary-type-assertion doesn't report template literals with expressions Jan 17, 2025
@ronami ronami marked this pull request as ready for review January 17, 2025 14:36
@kirkwaiblinger
Copy link
Member

should we just use declare let/declare const to sidestep any complexity about the possible type?

@kirkwaiblinger kirkwaiblinger added the awaiting response Issues waiting for a reply from the OP or another party label Jan 19, 2025
@ronami
Copy link
Member Author

ronami commented Jan 19, 2025 •
edited
Loading

should we just use declare let/declare const to sidestep any complexity about the possible type?

Hmm since these two are different types (one is a "fresh literal", the other isn't):

// not a "fresh literal"
declare const a: 'foo';

// is a "fresh literal"
const b = 'foo';

Along with seeing how much complexity there is around "fresh literals", I've changed both tests to use declare const but also added one test for a standard "fresh literal" const key = ... usage. I'm not sure if it's really necessary though, I'm totally OK removing it too.

Wdyt?

Edit: I manually removed the awaiting response label, as I think there's no review to ask for a re-review.

@ronami ronami removed the awaiting response Issues waiting for a reply from the OP or another party label Jan 19, 2025
@codecov Codecov
Copy link

codecov bot commented Jan 19, 2025 •
edited
Loading

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 87.15%. Comparing base (31be053) to head (27ba6f7).
Report is 13 commits behind head on main.

Additional details and impacted files 
@@           Coverage Diff           @@
##             main   #10671   +/-   ##
=======================================
  Coverage   87.15%   87.15%           
=======================================
  Files         448      448           
  Lines       15576    15578    +2     
  Branches     4551     4551           
=======================================
+ Hits        13575    13577    +2     
  Misses       1645     1645           
  Partials      356      356
Flag Coverage Δ
unittest 87.15% <ø> (+<0.01%) ⬆️

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

see 2 files with indirect coverage changes

@kirkwaiblinger kirkwaiblinger added the 1 approval >=1 team member has approved this PR; we're now leaving it open for more reviews before we merge label Jan 20, 2025
@JoshuaKGoldberg JoshuaKGoldberg merged commit 609a78f into typescript-eslint:main Jan 20, 2025
64 of 66 checks passed
@ronami ronami deleted the fix-no-unnecessary-type-assertion-template-literal-tests branch January 20, 2025 15:15
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Jan 28, 2025
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Reviewers

@kirkwaiblinger kirkwaiblinger kirkwaiblinger approved these changes

Assignees
No one assigned
Labels
1 approval >=1 team member has approved this PR; we're now leaving it open for more reviews before we merge
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
3 participants
@ronami @kirkwaiblinger @JoshuaKGoldberg