You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As mentioned here, @iconfiy/json style icon sets are currently not supported by the customCollections attribute of unplugin-icons. Support for this feature would be very helpful to integrate commercial icons like Font Awesome Pro.
As an alternative to supporting json style icon sets a the loader function could be extended to apply the fill="currentColor" attribute and other useful defaults (see @iconify/utils/lib/customisations) to SVG files. This way commercial icons like Font Awesome Pro could be loaded directly.
Personally, I lean towards the alternative because it removes the JSON build step that's required for the first approach. Having said that, I'm not familiar with the implications of not going with the JSON approach.
The text was updated successfully, but these errors were encountered:
I am not sure if what ./json/fab.json in your code snippet really is. But if it's compatible with Iconify's json data, I think we could export the icon resolver and maybe add an IconifyLoader to be reused for custom sources.
Meanwhile, I see your use FileSystemLoader in your first approach, #12 (comment), if that's preferable, we could have a custom transform function to FileSystemLoader as mentioned in #52.
As mentioned here, @iconfiy/json style icon sets are currently not supported by the
customCollections
attribute of unplugin-icons. Support for this feature would be very helpful to integrate commercial icons like Font Awesome Pro.As an alternative to supporting json style icon sets a the loader function could be extended to apply the
fill="currentColor"
attribute and other useful defaults (see@iconify/utils/lib/customisations
) to SVG files. This way commercial icons like Font Awesome Pro could be loaded directly.Personally, I lean towards the alternative because it removes the JSON build step that's required for the first approach. Having said that, I'm not familiar with the implications of not going with the JSON approach.
The text was updated successfully, but these errors were encountered: