FE-620: DS icon component

[alex-e-leon]

🌟 What is the purpose of this PR?

Adds an Icon component to the DS. Once I've created a button component and updated petrinaut to use this component I may need to come back and update some properties.

Because we are using font awesome's pro icon set we can't re-export (or import) all of font-awesomes Icon set, so instead I've manually copied over the subset that we use. We also won't be able to allow users to select an icon in our UI's so we'll need to ban that ui pattern somehow.

Pre-Merge Checklist 🚀

This PR:

• modifies an npm-publishable library and I have added a changeset file(s)

📜 Does this require a change to the docs?

The changes in this PR:

• are internal and do not require a docs change

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
hash	Ready	Preview, Comment	Apr 29, 2026 1:26pm
hashdotdesign-tokens	Ready	Preview, Comment	Apr 29, 2026 1:26pm
petrinaut	Error		Apr 29, 2026 1:26pm

[cursor]

PR Summary

Medium Risk
Introduces a large set of bundled SVG assets and new SVGR build tooling, which can affect bundle size and library build/consumer compatibility if SVG transforms or type declarations differ across environments.

Overview
Adds a new Icon component to @hashintel/ds-components, backed by an internal map of bundled Font Awesome SVGs, with size variants (xs–lg) and basic accessibility via optional alt.

Updates the package build/demo pipeline to support importing .svg files as React components (adds SVGR to tsdown and Vite/Ladle typings), exports Icon/IconName/iconNames from src/main.ts, and includes a changeset for a patch release.

^{Reviewed by Cursor Bugbot for commit 14d7e16. Bugbot is set up for automated code reviews on this repo. Configure here.}

[augmentcode]

🤖 Augment PR Summary

Summary: Adds a new Icon component to @hashintel/ds-components using a curated subset of Font Awesome Pro SVGs.
Changes:

• Added Icon component with name→SVG mapping and size variants (xs–lg)
• Added Panda recipe (icon.recipe.ts) to standardize sizing via --icon-size
• Added Ladle stories to demo default usage, sizes, and an icon grid
• Moved Ladle type declarations into .ladle/types.d.ts and added an SVG module declaration
• Enabled SVG-to-React importing for Ladle via vite-plugin-svgr in vite.config.ts
• Added a license notice alongside the copied SVG assets

Why: Font Awesome Pro icons can’t be wholesale re-exported, so the DS ships only the subset used by HASH.

_{🤖 Was this summary useful? React with 👍 or 👎}

[augmentcode]

Review completed. 3 suggestions posted.

Comment augment review to trigger a new review at any time.

[lunelson]

So, FTR I must say I'm not convinced svgr should be our solution for integrating Font Awesome Pro icons in the DS. It provides good local ergonomics, but the SVG markup becomes part of the shipped JS and part of React’s rendered tree, which costs in bundle size, parse/compile work, and more React-managed markup and memory overhead

Personally I’d strongly prefer something like:

• maintain an explicit approved icon manifest;
• generate subset sprite files containing only icons actually used by the product;
• expose a very small Icon component that renders <svg><use href="...#icon-name" /></svg>;
• style via panda tokens / currentColor, not icon-specific component APIs

[lunelson]

Some context: Breaking Up with SVG-in-JS

[alex-e-leon]

So, FTR I must say I'm not convinced svgr should be our solution for integrating Font Awesome Pro icons in the DS. It provides good local ergonomics, but the SVG markup becomes part of the shipped JS and part of React’s rendered tree, which costs in bundle size, parse/compile work, and more React-managed markup and memory overhead

Personally I’d strongly prefer something like:

• maintain an explicit approved icon manifest;
• generate subset sprite files containing only icons actually used by the product;
• expose a very small Icon component that renders <svg><use href="...#icon-name" /></svg>;
• style via panda tokens / currentColor, not icon-specific component APIs

I 100% agree - I plan on implementing spriting down the line.

I've used svgr for now because its much simpler to setup and get working, while I'm a little uncertain how the pipeline for spriting will work for consumers right now.

My plan was once I've finished a couple of these components and got a consumer (likely petrinaut) actually consuming the icons properly to then come back and implement spriting so that I have a real consumer to test the spriting pipeline.

[alex-e-leon]

• maintain an explicit approved icon manifest;

What exactly do you mean by a manifest?

• style via panda tokens / currentColor, not icon-specific component APIs

Agree - this is how the icon component works at the moment.

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 41b4603. Configure here.}

[lunelson]

• What exactly do you mean by a manifest?

Just a central definition of which icons should go in to the sprite