Why don’t you declare the icons as ES Modules, so they’re fully tree-shakable?

[fivaz3]

You wouldn’t have to deal with the hassle of manually adding the icons you’re going to use in the vite.config.js.

Even if your library has millions of icons, all of them would be available during development, but only the ones actually used would be included in the final build shipped to the client.

[oktaysenkan]

I don’t like multiple imports for icons but i can add this feature later.

Example usage

import UserIcon from "@monicon/lucide/user"
import AccountIcon from "@monicon/lucide/account"

[fivaz3]

thanks, it would be great

[benweier]

@oktaysenkan This would be far more preferable than adding individual icon names to the build config or unnecessarily bloating the bundle with an entire collection. I'd love to recommend we adopt Monicon within my workplace, as the standard icon solution for all our apps, but unfortunately I can't do that if the DX every time is "use an icon.. check the config"

[oktaysenkan]

I am thinking a solution for this. Metro does not provide module load function like Vite.

[oktaysenkan]

I just created the issue on metro repo

https://github.com/facebook/metro/issues/1422

[oktaysenkan]

I will build a CLI tool to automate the generation of icon files in different formats (.tsx, .jsx, .vue, .svg, etc.). This enables fully tree shakable icons.

Core Features:

• Users can set a custom output path (default: src/components/icon).
• Supports predefined templates for different frameworks (SVG, React JSX, React TSX, Vue, etc.).
• Allows users to define custom templates, similar to a custom loader, making it possible to use Monicon in other programming languages.

This will streamline icon management and improve workflow efficiency. What do you think?