Export SVGs directly.

[lgarron]

This issue comes from thewca/worldcubeassociation.org#10526

Icon fonts work fine, but conceptually (and for performance, depending on how things are set up) it would be nicer to allow loading SVGs directly. If we introduce this, I'd like it to:

• Be easy to use on the client (for dynamic apps) using standardized technologies.
• Be easy to use on the server using common runtimes.
• Avoid any proprietary conventions like React.

We'd have to review/resize/lint our SVGs more carefully to support this as well.

I don't have a strong opinion on whether it should be easy to inline the SVG source vs. loading it as an image (or which should even be the default).

One option would be to give each icon its own export, e.g.

• @cubing/icons/svg/official/333
• @cubing/icons/svg/unofficial/222

But I suspect this will not be ergonomic enough for some use cases. Hopefully there's a good convention for this. (Perhaps React is now sufficiently compatible with custom elements?)

[jfly]

Related: #28

I agree with above: I don't want to ship react components here. Let's find a portable, standards compliant way of doing this.

Doing a svg sprite (as described in linked issue) smells reasonable to me if we can't find a better option.

What are popular icon packs doing these days? Still shipping web fonts?

[gregorbg]

I do not have a vast overview of icon packages outside of React, but within that ecosystem https://github.com/react-icons/react-icons is wildly popular.

Their whole build pipeline is basically just a big index of where to find SVG files, and then one (relatively small) snippet of converting a given SVG into a named component export.

I am perfectly fine if you don't ship ready-made React components like they do. That sort of commitment to an ecosystem would feel out of place for your general-purpose icon package. But within the contraints of what we (ideally) need for the main website, I can testify that exporting or otherwise exposing the SVGs to us would be more than enough to easily pack them into our own components.

[mintydev789]

So how are we supposed to use this library after the last couple PRs? I notice there's some new icons, but there is no new NPM release.

[lgarron]

So how are we supposed to use this library after the last couple PRs? I notice there's some new icons, but there is no new NPM release.

Using the published package. @jfly and I need to talk through some stuff before releasing.

Are you commenting here because you'd like to use SVG exports?

[mintydev789]

So how are we supposed to use this library after the last couple PRs? I notice there's some new icons, but there is no new NPM release.

Using the published package. @jfly and I need to talk through some stuff before releasing.

Are you commenting here because you'd like to use SVG exports?

I was just a little confused, as I assumed this new feature will replace the current way of consuming the icons through the NPM package

[lgarron]

So how are we supposed to use this library after the last couple PRs? I notice there's some new icons, but there is no new NPM release.

Using the published package. @jfly and I need to talk through some stuff before releasing.
Are you commenting here because you'd like to use SVG exports?

I was just a little confused, as I assumed this new feature will replace the current way of consuming the icons through the NPM package

Yeah, we wouldn't break compat like that without a really good reason and a deprecation period.

[mintydev789]

So how are we supposed to use this library after the last couple PRs? I notice there's some new icons, but there is no new NPM release.

Using the published package. @jfly and I need to talk through some stuff before releasing.
Are you commenting here because you'd like to use SVG exports?

I was just a little confused, as I assumed this new feature will replace the current way of consuming the icons through the NPM package

Yeah, we wouldn't break compat like that without a really good reason and a deprecation period.

Ah, right. Makes sense then. I'll just wait for the next package version.

[lgarron]

Expanding here a bit to help the discussion in #211:

npm packages have an "exports" field, and I still believe this is by far the best way to declare what can be imported from our package: https://docs.npmjs.com/cli/v11/configuring-npm/package-json#exports
I think relying on anything less explicit as our package API will cause technical debt and unfortunate surprises over time.

If we want to export SVGs directly I think we should be very deliberate about what export paths we would want to commit to.

• Do we want to export paths from the filesystem (similar to Include SVGs in NPM package #210) or an abstraction (similar to the first comment here)? The former is fine, but I think we should not publish the files out out of src folder if we do so.
• If an event becomes official, how do we want to handle the transition? In JavaScript and CSS we can keep around old aliases cheaply and have some (admittedly imperfect) options to mark them as deprecated, but if we expose our file system directly we need to figure out how long to keep around duplicate files. (Note that there is no way to mark path exports as deprecated or canonical.)
• Some of our SVGs are not optimized and can have rendering issues in some circumstances. We have some discussions and PRs about fixing this up, but I don't know if it quite addresses everything.
• Are there any particular ways of structuring this that work well or badly with common runtimes, bundlers, or frameworks? My understanding is that some of them support some wild globbing semantics.
  • I would even go so far as to suggest that our CSS could be based on importing the SVG files, but I don't think there will be a portable way to do this for some time.

Depending on what we're comfortable with requiring in PRs vs. what we want in the published package, we may need a build step for the SVGs.