fix(nuxt): handle TS type assertions on member expression callees in keyed functions parser

[oritwoen]

parseStaticFunctionCall already unwraps TS type assertions (as, angle-bracket casts, !) for simple callees like (useFetch as any)(), and it handles member expressions like factories.createUseFetch(). But when both are combined - a parenthesized type assertion wrapping a member expression - the parser bails and returns null.

That means patterns like (factories.createUseFetch as any)(), (factories.createUseFetch!)(), or (<any>factories.createUseFetch)() never get a key injected by the compiler, which can lead to state collisions or hydration mismatches at runtime.

The fix unwraps one layer of TS assertion inside the parenthesized expression before checking for a member expression, same approach already used for the simple callee branch. Resolves the TODO on the same line.

[bolt-new-by-stackblitz]

Run & review this pull request in StackBlitz Codeflow.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro

Run ID: 8dcc1e2a-f65d-477f-b58c-779194c8662b

📥 Commits

Reviewing files that changed from the base of the PR and between 78fa3fd and e61d50d.

📒 Files selected for processing (2)

• packages/nuxt/src/core/utils/parse-utils.ts
• packages/nuxt/test/compiler.test.ts

---

Walkthrough

This change extends the parseStaticFunctionCall utility to handle function calls where the callee is a parenthesised expression wrapping a member expression, with optional TypeScript type assertions or non-null assertions. The implementation unwraps these TypeScript constructs to reach the underlying member expression, then parses it to extract function metadata. Existing behaviour for straightforward member expression and identifier-based calls is preserved. Corresponding test cases are added to validate parsing accuracy for TypeScript casting and assertion scenarios.

🚥 Pre-merge checks | ✅ 2 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 50.00% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title accurately describes the main change: handling TypeScript type assertions on member expression callees in the parser, which matches the file changes and objectives.
Description check	✅ Passed	The description clearly explains the problem (missing key injection for TS-wrapped member expressions), impact (state collisions and hydration mismatches), and solution (unwrapping TS assertions before checking member expressions), directly matching the changeset.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

📝 Coding Plan

• Generate coding plan for human review comments

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[pkg-pr-new]

Open in StackBlitz

@nuxt/kit

npm i https://pkg.pr.new/@nuxt/kit@34558

@nuxt/nitro-server

npm i https://pkg.pr.new/@nuxt/nitro-server@34558

nuxt

npm i https://pkg.pr.new/nuxt@34558

@nuxt/rspack-builder

npm i https://pkg.pr.new/@nuxt/rspack-builder@34558

@nuxt/schema

npm i https://pkg.pr.new/@nuxt/schema@34558

@nuxt/vite-builder

npm i https://pkg.pr.new/@nuxt/vite-builder@34558

@nuxt/webpack-builder

npm i https://pkg.pr.new/@nuxt/webpack-builder@34558

commit: 0c84374

[codspeed-hq]

Merging this PR will not alter performance

✅ 20 untouched benchmarks
⏩ 3 skipped benchmarks¹

---

_{Comparing oritwoen:fix/parse-member-expression-type-assertions (e61d50d) with main (78fa3fd)}

Footnotes

1. 3 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩