fix(compiler-sfc): resolve numeric literals and template literals without expressions as static property key

[KazariEX]

fix #13937 (comment)

Summary by CodeRabbit

• New Features

  • Support for template-literal-style and numeric-style prop keys in type-based prop declarations (e.g., _foo_x_, 123).

• Improvements

  • Broader, more consistent handling of computed and template-literal property names for more accurate type inference.
  • Improved mapping of template-derived prop name patterns via enhanced iteration/mapping logic.

• Bug Fixes

  • Adjusted runtime expectations to align with expanded key types (boolean/symbol identification).

[coderabbitai]

Walkthrough

Updated type-key extraction and mapping in compiler-sfc: added a string-literal key helper, switched resolveType to use it for static and computed keys, removed separate TemplateLiteral handling, and added tests covering template-literal and numeric literal prop keys and mapped template-literal types.

Changes

Cohort / File(s)	Summary
Type resolution / resolve packages/compiler-sfc/src/script/resolveType.ts	Replaced uses of getId with getStringLiteralKey/string-literal-based extraction for static and computed property keys in typeElementsToMap and findStaticPropertyType; removed separate TemplateLiteral branch.
Utilities / key extraction packages/compiler-sfc/src/script/utils.ts	Added exported `getStringLiteralKey(node: TSPropertySignature
Tests packages/compiler-sfc/__tests__/compileScript/resolveType.spec.ts	Updated tests: added template-literal key [`qux`]: boolean, numeric literal key 123: symbol, and changed mapped-template type from [`_\${T}_\${S}_`]: string to [K in \${T}${S}_`]: string to reflect mapped key iteration and expected runtime types (qux: ['Boolean'], 123: ['Symbol']`).

Sequence Diagram(s)

sequenceDiagram
    participant Test as Test (spec)
    participant Resolver as resolveType.typeElementsToMap / findStaticPropertyType
    participant Utils as utils.getStringLiteralKey

    Note over Test,Resolver: New key extraction flow for prop/type keys
    Test->>Resolver: provide type element (Identifier | StringLiteral | NumericLiteral | TemplateLiteral | computed)
    Resolver->>Utils: getStringLiteralKey(node)
    alt returns non-null string key
        Utils-->>Resolver: "key" (e.g., "qux", "123", "_foo_x_")
        Resolver-->>Test: create map entry with extracted key and inferred runtime type
    else returns null
        Utils-->>Resolver: null
        Resolver-->>Test: skip/handle as unsupported computed key
    end

Loading

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

Suggested labels

ready to merge, scope: sfc, :hammer: p3-minor-bug

Poem

🐇 I join quasis, count each stitch and seam,
Numbers and backticks now share one dream,
Keys once scattered, now hop in a line,
Props map cleanly — carrots for the mind! 🥕

Pre-merge checks and finishing touches

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	You can run @coderabbitai generate docstrings to improve docstring coverage.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title Check	✅ Passed	The pull request title "fix(compiler-sfc): resolve numeric literals and template literals without expressions as static property key" is directly related to the main changes in the changeset. The code modifications add support for resolving numeric literals (which are stringified) and template literals without expressions as static property keys in type definitions through a new getStringLiteralKey function and its integration into key resolution logic. The title accurately captures what is being fixed, specifies the affected package scope (compiler-sfc), and is clear and specific enough for a developer scanning history to understand the primary change.

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

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

---

📜 Recent review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 604cfdf and 5ce53c0.

📒 Files selected for processing (3)

• packages/compiler-sfc/__tests__/compileScript/resolveType.spec.ts (2 hunks)
• packages/compiler-sfc/src/script/resolveType.ts (3 hunks)
• packages/compiler-sfc/src/script/utils.ts (2 hunks)

🚧 Files skipped from review as they are similar to previous changes (2)

• packages/compiler-sfc/tests/compileScript/resolveType.spec.ts
• packages/compiler-sfc/src/script/utils.ts

🧰 Additional context used

🧬 Code graph analysis (1)

packages/compiler-sfc/src/script/resolveType.ts (1)

packages/compiler-sfc/src/script/utils.ts (1)

• getStringLiteralKey (84-98)

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (4)

• GitHub Check: Redirect rules
• GitHub Check: Header rules
• GitHub Check: Pages changed
• GitHub Check: test / e2e-test

🔇 Additional comments (3)

packages/compiler-sfc/src/script/resolveType.ts (3)

32-32: LGTM! Import addition is correct.

The getStringLiteralKey helper is properly imported and used consistently throughout the file.

---

340-349: Excellent improvement for key resolution.

The switch to getStringLiteralKey(e) properly handles template literals without expressions and numeric literal keys, treating them as static string keys. The null check correctly falls through to the error handler for unsupported computed keys.

---

2025-2033: Good consistency with typeElementsToMap.

Updating findStaticPropertyType to use getStringLiteralKey(m) ensures both functions use the same key resolution logic, which is essential for correctly matching properties with template literal or numeric literal keys.

---

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.}

[github-actions]

Size Report

Bundles

File	Size	Gzip	Brotli
runtime-dom.global.prod.js	102 kB	38.6 kB	34.8 kB
vue.global.prod.js	160 kB	58.7 kB	52.2 kB

Usages

Name	Size	Gzip	Brotli
createApp (CAPI only)	46.7 kB	18.3 kB	16.7 kB
createApp	54.7 kB	21.3 kB	19.5 kB
createSSRApp	58.9 kB	23 kB	21 kB
defineCustomElement	60 kB	23 kB	21 kB
overall	68.8 kB	26.5 kB	24.2 kB

[pkg-pr-new]

Open in StackBlitz

@vue/compiler-core

npm i https://pkg.pr.new/@vue/compiler-core@13998

@vue/compiler-dom

npm i https://pkg.pr.new/@vue/compiler-dom@13998

@vue/compiler-sfc

npm i https://pkg.pr.new/@vue/compiler-sfc@13998

@vue/compiler-ssr

npm i https://pkg.pr.new/@vue/compiler-ssr@13998

@vue/reactivity

npm i https://pkg.pr.new/@vue/reactivity@13998

@vue/runtime-core

npm i https://pkg.pr.new/@vue/runtime-core@13998

@vue/runtime-dom

npm i https://pkg.pr.new/@vue/runtime-dom@13998

@vue/server-renderer

npm i https://pkg.pr.new/@vue/server-renderer@13998

@vue/shared

npm i https://pkg.pr.new/@vue/shared@13998

vue

npm i https://pkg.pr.new/vue@13998

@vue/compat

npm i https://pkg.pr.new/@vue/compat@13998

commit: 5ce53c0