With astro-icon@0.8.2 we were fetching SVG icons from CDN on demand and caching them in app memory using createIconPack. Since astro-icon@1.0.0 it is no longer possible to do that (https://www.astroicon.dev/guides/upgrade/v1/#removed-createiconpack-utilities) - you can either depend on preinstalled iconify sets or store .svg locally. The new approach is not an option since the icon src is coming from CMS and we select them from a much larger pool of icons in CDN. Wondering if there's any other approach to continue using the same approach with or without astro-icon? Any of you guys encountered similar situation?
#astro-icon no longer supports dynamic svg rendering
shell zodiac
zealous sage
Hey there! Sorry to hear about your Icon issues 😦
Personally I keep mine locally so I'm not 100% sure of a solution to your problem but figured I would get you in touch with an expert (the astro-icon author) 🙂
cc @untold rivet
pallid kestrel
Could just stay on the old version of astro icon 🙂
But real talk - would it work if you have all icons already stored locally, or had those pack installed? Like if on the CMS it's limited to tabler icons, could you just have the tabler icons pack installed and setup like astro-icon wants?
shell zodiac
@zealous sage appreciate the input 🙇♂️ @pallid kestrel without a bigger rework migration is not possible so we might end up with this version for a while 😅 For some additional information - that is kind of what we already do with font-awesome which is our primary way of selecting icons in the CMS (selected from a limited drop down options). This approach was kind of meant to enable content managers to have a quick way to add some custom or experimental icon from designers. It seems that for now we can disable optimizations with the prop (a new feature requires that), apply only what is needed oursleves and continue with the existing version until we run into bigger problems.