fix(eslint-plugin): [strict-boolean-expressions] consider assertion function argument a boolean context

[kirkwaiblinger]

PR Checklist

• Addresses an existing open issue: fixes Enhancement: [strict-boolean-expressions] Check truthiness assertion functions #9009
• That issue was marked as accepting prs
• Steps in Contributing were taken

Overview

Query for call expressions, check if the function being called is an assertion function, and line up the asserted parameter with the arguments that we see.

[typescript-eslint]

Thanks for the PR, @kirkwaiblinger!

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	524c870
🔍 Latest deploy log	https://app.netlify.com/sites/typescript-eslint/deploys/663eb9e6552d9700083ff8b5
😎 Deploy Preview	https://deploy-preview-9074--typescript-eslint.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.
Lighthouse	1 paths audited Performance: 91 (🔴 down 5 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 Report

CI is running/has finished running commands for commit 524c870. 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

---

✅ Successfully ran 31 targets

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

---

Sent with 💌 from NxCloud.

[JoshuaKGoldberg]

I squinted at the logic a bunch and it all seems pretty reasonable. Nice stuff. Requesting changes to add some tests just to be sure though. ✨

[JoshuaKGoldberg]

[Style] Nit: I'm always surprised we don't have a rule for this ... somewhere.

Suggested change

	firstParameter != null &&
	firstParameter.name.kind === ts.SyntaxKind.Identifier &&
	firstParameter?.name.kind === ts.SyntaxKind.Identifier &&

[JoshuaKGoldberg]

[Docs] This is very nitpicky, but unnecessary _"even"_s have always bugged me.

Suggested change

	// Don't even bother inspecting parameters past the number of
	// Don't bother inspecting parameters past the number of

[JoshuaKGoldberg]

[Docs] Nit: everywhere else generally refers to assert(), and that's a pretty commonly used name. I think it'd be nice to use it here for consistency.

Suggested change

	declare function myAssert(value: unknown): asserts value;
	let maybeString = Math.random() > 0.5 ? '' : undefined;
	myAssert(maybeString);
	declare function assert(value: unknown): asserts value;
	let maybeString = Math.random() > 0.5 ? '' : undefined;
	assert(maybeString);

[JoshuaKGoldberg]

[Refactor] Totally optional, but I had a bit of a hard time figuring out the intended flow of all the added code. There's a lot. Extracting out the "what is the asserted parameter index?" logic into a separate might be helpful in making that more clear. What do you think?

Suggested change

	const assertedParameter = checkableArguments[assertedParameterIndex];
	traverseNode(assertedParameter, true);
	const assertedParameter = getAssertedParameter(checkableArguments, node);
	if (assertedParameter) {
	traverseNode(assertedParameter, true);
	}

[JoshuaKGoldberg]

[Testing] Some more test cases I think would be good to have:

• Combining this: and function overloads
• Three very different overloads
• ... params, including in combination with the other two things