On top of existing icon libraries like heroicons, I'd like to be able to easily create a new icon library myself (e.g export a bunch of svgs from Figma etc), run them through a build process (as used in this repo in build.ts), bundle them in its own package and consume them via a Icon component (like in this repo src/lib/Icon.svelte )
This sounds like alot of work to do, but could be simplified in my eyes. It would enable alot of flexibility when done in a consistent way since you could use any existent "icon sources" that meet a specific requirement.
This approach would end up in these different parts:
a package that serves the Icon Component (or maybe more than one e.g one that is configured more accessible)
n packages that serve the Icon Sources (e.g heroicons, etc ) of a certain format
a minimal Template Project (favorable a sveltekit project) to produce and package the Icon Sources from 2.
Implementation Ideas
For point 1. I would take src/lib/Icon.svelte as reference. The solid attribute gets replaces with a new attribute called type or theme of type string with a default value of default. This can be seen as an Icon Theme where each Icon Source has at least one theme called default but can also have many more for the same Icon. If we take heroicons as an example, the default theme would be the outline version of the icons. Additionally the solid versions could be another theme that are associated with an icon. Having it that way you aren't anymore bound to a set number of icon versions and can have many different ones.
For point 2 a converter needs to transform a regular .svg file into a .js file that can be consumed by the Icon Component.
e.g for heroicons having the original svg sources in
themes/default/annotation.svg
themes/solid/annotation.svg
Would produce a Icon Source file:
//$lib/icons/Annotation.js
export default {
default: {
//attributes of the svg element
xmlns: "http://www.w3.org/2000/svg", fill: "none", viewBox: "0 0 24 24", stroke: "currentColor", "aria-hidden": "true",
//the svg path data
paths: [
{
"fill-rule": "evenodd",
d: "M18 13V5a2...",
"clip-rule": "evenodd",
},
]
},
solid: {
//attributes of the svg element
xmlns:"http://www.w3.org/2000/svg",viewBox:"0 0 20 20", fill:"currentColor", "aria-hidden":"true",
//the svg path data
paths: [
{
"stroke-linecap": "round",
"stroke-linejoin": "round",
"stroke-width": "2",
d: "M7 8h10M7...",
},
]
}
}
The Icon Component then takes the data depending on the theme or type attribute and renders the svg accordingly
As for point 3. the source code of this repo could be adjusted and documented to serve as a "Icon Source Builder Template" or as you will call it, for anyone to publish their icon libraries of choice (if not already existent)
Most of this stuff could be part of a monorepo under a different project name. What do you think ?
Why
On top of existing icon libraries like heroicons, I'd like to be able to easily create a new icon library myself (e.g export a bunch of svgs from Figma etc), run them through a build process (as used in this repo in
build.ts
), bundle them in its own package and consume them via a Icon component (like in this reposrc/lib/Icon.svelte
)This sounds like alot of work to do, but could be simplified in my eyes. It would enable alot of flexibility when done in a consistent way since you could use any existent "icon sources" that meet a specific requirement.
This approach would end up in these different parts:
Icon Component
(or maybe more than one e.g one that is configured more accessible)Icon Sources
(e.g heroicons, etc ) of a certain formatTemplate Project
(favorable a sveltekit project) to produce and package theIcon Sources
from 2.Implementation Ideas
For point 1. I would take
src/lib/Icon.svelte
as reference. The solid attribute gets replaces with a new attribute calledtype
ortheme
of type string with a default value ofdefault
. This can be seen as an Icon Theme where eachIcon Source
has at least one theme calleddefault
but can also have many more for the same Icon. If we take heroicons as an example, the default theme would be the outline version of the icons. Additionally the solid versions could be another theme that are associated with an icon. Having it that way you aren't anymore bound to a set number of icon versions and can have many different ones.For point 2 a converter needs to transform a regular .svg file into a .js file that can be consumed by the
Icon Component
. e.g for heroicons having the original svg sources inWould produce a
Icon Source
file:The
Icon Component
then takes the data depending on thetheme
ortype
attribute and renders the svg accordinglyAs for point 3. the source code of this repo could be adjusted and documented to serve as a "Icon Source Builder Template" or as you will call it, for anyone to publish their icon libraries of choice (if not already existent)
Most of this stuff could be part of a monorepo under a different project name. What do you think ?