Skip to content

fix(Icon): improve name type #5498

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

Merged
merged 2 commits into from
Nov 21, 2025
+1 −1
Merged

fix(Icon): improve name type #5498

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
96dbce7
fix(types): fix IconProps' name type
KazimirPodolski Nov 20, 2025
3dc5ab9
fix(types): fix IconProps' name type
KazimirPodolski Nov 21, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion src/runtime/components/Icon.vue
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
<script lang="ts">
export interface IconProps {
name: string | object
name: string | any
Comment on lines 2 to +3
Copy link
Contributor

@vercel vercel bot Nov 21, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
export interface IconProps {
name: string | object
name: string | any
import type { Component } from 'vue'
export interface IconProps {
name: string | Component

The type definition uses any instead of properly supporting functional components, which disables TypeScript type checking and doesn't match the PR description that states it should "accept Function".

View Details

Analysis

Icon component type definition loses TypeScript type safety

What fails: IconProps.name type definition uses string | any instead of string | Component, which disables TypeScript type checking and allows invalid values like numbers and booleans to be passed without errors.

How to reproduce:

import type { Component } from 'vue'

// Current broken implementation (string | any)
interface BrokenIconProps {
  name: string | any
}

// This incorrectly passes type checking:
const badProps: BrokenIconProps = { name: 123 }      // Should error
const badProps2: BrokenIconProps = { name: true }    // Should error

// Fixed implementation (string | Component)
interface FixedIconProps {
  name: string | Component
}

// These correctly fail type checking:
// @ts-expect-error
const goodProps: FixedIconProps = { name: 123 }      // Error: Type 'number' not assignable

Result with current any type: TypeScript allows any value to be assigned to name without warnings, including 123, true, or other invalid values.

Expected behavior: TypeScript should reject non-component values. Using string | Component (from Vue's official type exports) provides proper type safety for component definitions.

Note: The component logic at lines 25-26 correctly handles both strings and components at runtime with typeof name === 'string' checks, but TypeScript type safety was removed when the prop type was changed from string | Component (commit 96dbce7) to string | any (commit 3dc5ab9). This fix restores proper type checking while maintaining backward compatibility with the existing runtime behavior.

Copy link
Member

@benjamincanac benjamincanac Nov 21, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We'll put back Component when possible!

mode?: 'svg' | 'css'
size?: string | number
customize?: (
Expand Down
Loading