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

✅ Deploy Preview fortypescript-eslint ready!

Name	Link
🔨 Latest commit	f003891
🔍 Latest deploy log	https://app.netlify.com/sites/typescript-eslint/deploys/675dcf12358ef90008b5f44b
😎 Deploy Preview	https://deploy-preview-10472--typescript-eslint.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.
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 yourNetlify site configuration.

☁️ Nx Cloud Report

CI is running/has finished running commands for commitf003891. As they complete they will appear below. Click to see the status, the terminal output, and the build insights.

📂 See all runs for this CI Pipeline Execution

Sent with 💌 fromNxCloud.

Noting that there are a fair number of problematic usages of "cast" remaining that we'll want to address still, either here or in a followup

I've just realized my VSCode had match-case and match-whole-word locked in (🙈). I think I've managed to update every usage ofcast that refers to a type assertion.

Thanks!

Looks like there's still two more places where "cast" is used in user-facing strings...

... and then also here, though I'm honestly not sure why we even have this:

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 86.78%. Comparing base(2c8a75e) to head(f003891).
Report is 31 commits behind head on main.

@@            Coverage Diff             @@##             main   #10472      +/-   ##==========================================+ Coverage   86.76%   86.78%   +0.02%==========================================  Files         444      445       +1       Lines       15311    15365      +54       Branches     4457     4475      +18     ==========================================+ Hits        13285    13335      +50- Misses       1672     1675       +3- Partials      354      355       +1

Looks like there's still two more places where "cast" is used in user-facing strings...

typescript-eslint/packages/eslint-plugin/src/rules/strict-boolean-expressions.ts

Line 71 ind09d36d

'An explicit comparison or type cast is required.',

typescript-eslint/packages/eslint-plugin/src/rules/strict-boolean-expressions.ts

Line 103 ind09d36d

'Explicitly cast value to a boolean (`Boolean(value)`)',

... and then also here, though I'm honestly not sure why we even have this:

typescript-eslint/packages/eslint-plugin/docs/rules/strict-boolean-expressions.mdx

Lines 171 to 201 ind09d36d

	##Fixes and Suggestions
	This rule provides following fixes and suggestions for particular types in boolean context:
	-`boolean` - Always allowed - no fix needed.
	-`string` - (when`allowString` is`false`) - Provides following suggestions:
	- Change condition to check string's length (`str` →`str.length > 0`)
	- Change condition to check for empty string (`str` →`str !== ""`)
	- Explicitly cast value to a boolean (`str` →`Boolean(str)`)
	-`number` - (when`allowNumber` is`false`):
	- For`array.length` - Provides**autofix**:
	- Change condition to check for 0 (`array.length` →`array.length > 0`)
	- For other number values - Provides following suggestions:
	- Change condition to check for 0 (`num` →`num !== 0`)
	- Change condition to check for NaN (`num` →`!Number.isNaN(num)`)
	- Explicitly cast value to a boolean (`num` →`Boolean(num)`)
	-`object | null | undefined` - (when`allowNullableObject` is`false`) - Provides**autofix**:
	- Change condition to check for null/undefined (`maybeObj` →`maybeObj != null`)
	-`boolean | null | undefined` - Provides following suggestions:
	- Explicitly treat nullish value the same as false (`maybeBool` →`maybeBool ?? false`)
	- Change condition to check for true/false (`maybeBool` →`maybeBool === true`)
	-`string | null | undefined` - Provides following suggestions:
	- Change condition to check for null/undefined (`maybeStr` →`maybeStr != null`)
	- Explicitly treat nullish value the same as an empty string (`maybeStr` →`maybeStr ?? ""`)
	- Explicitly cast value to a boolean (`maybeStr` →`Boolean(maybeStr)`)
	-`number | null | undefined` - Provides following suggestions:
	- Change condition to check for null/undefined (`maybeNum` →`maybeNum != null`)
	- Explicitly treat nullish value the same as 0 (`maybeNum` →`maybeNum ?? 0`)
	- Explicitly cast value to a boolean (`maybeNum` →`Boolean(maybeNum)`)
	-`any` and`unknown` - Provides following suggestions:
	- Explicitly cast value to a boolean (`value` →`Boolean(value)`)

I've noticed these, too, but to my understanding, the meaning in those cases is actually to cast rather than to assert.

They all require the developer to make a runtime change rather than a type-only assertion. For example, these two reports (1,2) include a suggestion to "cast" a value to a boolean withBoolean(value).

I think these are similar to the coerce meaning in#10472 (comment), and also to the meaning of casting/coercing inno-extra-boolean-cast.

I'm not sure which terminology to use in those cases. There are some places we use the term coercing, some casting, and here (open PR) we use converting.

I've noticed these, too, but to my understanding, the meaning in those cases is actually to cast rather than to assert.

They all require the developer to make a runtime change rather than a type-only assertion. For example, these two reports (1,2) include a suggestion to "cast" a value to a boolean withBoolean(value).

I think these are similar to the coerce meaning in#10472 (comment), and also to the meaning of casting/coercing inno-extra-boolean-cast.

I'm not sure which terminology to use in those cases. There are some places we use the term coercing, some casting, and here (open PR) we use converting.

Gotcha, yeah, I see where you're coming from. My spiel on this is: within apure JS context, one can (just barely) get away with using "cast" as inno-extra-boolean-cast. IMO it's still not a good term for what it's describing, but it is at least unambiguous, since "cast" has no other possible meaning within JS. But, throwTS into the mix, and "cast" means different things to different people, and even sometimes different things to the same people in different contexts 😆. Therefore, I don't think we should use it for either the "type assertion" or "type conversion/coersion" meanings at all in a TS context.

So, then, to your specific question, I think we should change those terms in SBE, and we should change them to "convert"/"conversion". My vague idea of "coercion" vs "conversion" is that "coercion" is what happens when the language performs a type conversionimplicitly, usually because objects of incompatible types are interacting, liketrue + ''. So I'd think ofBoolean(x) as a conversion but not a coercion (but all coercions are conversions). Don't know if that's quite right, though;@Josh-Cena is generally our expert on these sorts of things!

Incidentally, regarding#10472 (comment), that does imply that the word "convert" would be most in line with my previous paragraph. But, the option name isignoreBooleanCoercion, so I think our hands are tied to use "coerce" in the description.

https://github.com/typescript-eslint/typescript-eslint/pull/10472/files/34610c6a07b3edc3acde8ae158a0f7472ced0f53#diff-a1ede3fb0351c7f188d7e9fcc7b931a865ebb2a0197b2323b3e104623812f76dR175-R179

I've noticed these, too, but to my understanding, the meaning in those cases is actually to cast rather than to assert.
They all require the developer to make a runtime change rather than a type-only assertion. For example, these two reports (1,2) include a suggestion to "cast" a value to a boolean withBoolean(value).
I think these are similar to the coerce meaning in#10472 (comment), and also to the meaning of casting/coercing inno-extra-boolean-cast.
I'm not sure which terminology to use in those cases. There are some places we use the term coercing, some casting, and here (open PR) we use converting.

Gotcha, yeah, I see where you're coming from. My spiel on this is: within apure JS context, one can (just barely) get away with using "cast" as inno-extra-boolean-cast. IMO it's still not a good term for what it's describing, but it is at least unambiguous, since "cast" has no other possible meaning within JS. But, throwTS into the mix, and "cast" means different things to different people, and even sometimes different things to the same people in different contexts 😆. Therefore, I don't think we should use it for either the "type assertion" or "type conversion/coersion" meanings at all in a TS context.

So, then, to your specific question, I think we should change those terms in SBE, and we should change them to "convert"/"conversion". My vague idea of "coercion" vs "conversion" is that "coercion" is what happens when the language performs a type conversionimplicitly, usually because objects of incompatible types are interacting, liketrue + ''. So I'd think ofBoolean(x) as a conversion but not a coercion (but all coercions are conversions). Don't know if that's quite right, though;@Josh-Cena is generally our expert on these sorts of things!

Incidentally, regarding#10472 (comment), that does imply that the word "convert" would be most in line with my previous paragraph. But, the option name isignoreBooleanCoercion, so I think our hands are tied to use "coerce" in the description.

https://github.com/typescript-eslint/typescript-eslint/pull/10472/files/34610c6a07b3edc3acde8ae158a0f7472ced0f53#diff-a1ede3fb0351c7f188d7e9fcc7b931a865ebb2a0197b2323b3e104623812f76dR175-R179

Yes! I can't agree more about how confusing "to cast" is, especially with TS, as it can have so many meanings.

I've updated the PR and adjusted the "to cast" usage in SBE, too; thanks!