Skip to content
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.

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

Icon type no longer exported. #1761

Closed
2 of 14 tasks
shyakadavis opened this issue Dec 27, 2023 · 4 comments · Fixed by #1762
Closed
2 of 14 tasks

Icon type no longer exported. #1761

shyakadavis opened this issue Dec 27, 2023 · 4 comments · Fixed by #1762
Labels
🐛 bug Something isn't working

Comments

@shyakadavis
Copy link
Contributor

shyakadavis commented Dec 27, 2023

Package

  • lucide
  • lucide-angular
  • lucide-flutter
  • lucide-preact
  • lucide-react
  • lucide-react-native
  • lucide-solid
  • lucide-svelte
  • lucide-vue
  • lucide-vue-next
  • Figma plugin
  • source/main
  • other/not relevant

Version

0.302.0

Description

If I try to import the type of an icon for using in a TS env, I get the error:

"lucide-svelte" has no exported member named Icon . Did you mean XIcon ?

Steps to reproduce

import type { Icon } from 'lucide-svelte';

export type Route = {
	name: string;
	icon: Icon;
	href: string;
};

Checklist

  • I have searched if someone has submitted a similar issue before and there weren't any. (Please make sure to also search closed issues, as this issue might already have been resolved.)
@shyakadavis shyakadavis added the 🐛 bug Something isn't working label Dec 27, 2023
@shyakadavis
Copy link
Contributor Author

Hey, @ericfennis, @AdrianGonz97

Sorry, but the issue that now arises is similar to the one from an earlier discussion; #1585 (reply in thread)

Type 'typeof Inbox' is missing the following properties from type 'SvelteComponent<IconProps, IconEvents, IconSlots>': $$prop_def, $$events_def, $$slot_def, $capture_state, and 6 more.ts(2740)
config.ts(24, 9): Did you mean to use 'new' with this expression?

@AdrianGonz97
Copy link
Contributor

Ah, this raises an interesting point, @shyakadavis.

The current solution for you would be to do what @lolcabanon suggested in the thread #1585 (reply in thread), to use ComponentType to derive the type of the Icon:

import type { ComponentType } from 'svelte';
import type { Icon } from 'lucide-svelte'; 

type TRoute = {
	name: string;
	path: string;
	icon: ComponentType<Icon>;
};

Now, is this solution ideal? Should the Icon type just alias to ComponentType<Icon> directly, such that the only thing a user must do is import and use the Icon type?

For example:

import type { Icon } from 'lucide-svelte'; 

type TRoute = {
	name: string;
	path: string;
	icon: Icon;
};

The advantage of this is convenience. But we do miss out on the opportunity on using the ComponentProps helper type to derive the props of an Icon like so:

import { Accessibility, Bean, type Icon } from "lucide-svelte";
import type { ComponentProps, ComponentType } from "svelte";
type TRoute = {
   name: string;
   path: string;
   icon: ComponentType<Icon>;
   props: ComponentProps<Icon>;
};

const routes: TRoute[] = [
   {
   	name: "foo",
   	path: "/foo",
   	icon: Accessibility,
   	props: {
   		size: 10
   	}
   },
   {
   	name: "bar",
   	path: "/bar",
   	icon: Bean,
   	props: {
   		size: 20,
   	}
   },
];

However, this may not be very intuitive, so I'm not quite sure what I'd prefer. @ericfennis was this what you had in mind when you originally exported the Icon type?

@lolcabanon
Copy link

lolcabanon commented Dec 28, 2023

@AdrianGonz97 IMO it's ok as-is since the ComponentType<T> is a Svelte thing that is written in the docs to extract the type of a component to pass it as a prop.

It's a bit like doing typeof Icon I guess, but with a Svelte utility type?

Maybe a note with example in lucide-svelte docs around the end where it is specified how to use a generic component would be great tho.

I'd be willing to do a PR for it if you'd like. Just tell me!

@shyakadavis
Copy link
Contributor Author

Ah, I see.

I don't think I have a great personal opinion about this, but it seems leaving stuff explicit is better.

That said, I opened a P.R; @AdrianGonz97, @lolcabanon please have a look and let me know if you think there's something to add/remove.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
🐛 bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants