SVG Icon Systems in Next.js: From Export to Production Component

A converted icon dropped into the App Router as a Server Component

No 'use client' — the converter output is a pure renderer, so Next.js ships zero client JS for it. Theming is a token class on the parent.

// src/components/icons/SearchIcon.tsx (from svg-to-jsx, TSX on)
import React from 'react';
export const SearchIcon = ({ className, ...props }: React.SVGProps<SVGSVGElement>): React.ReactElement => (
  <svg {...props} className={className} viewBox="0 0 24 24" fill="none"
       stroke="currentColor" strokeWidth="2">…</svg>
);
export default SearchIcon;

// app/(dashboard)/page.tsx — Server Component, no client JS
import { SearchIcon } from '@/components/icons';
<SearchIcon className="h-5 w-5 text-slate-400" aria-hidden />

Token-driven theming with currentColor

Define an icon token as a CSS variable mapped to a Tailwind utility, and every currentColor icon follows light/dark automatically. This only works because the SVG uses currentColor and the icon is inline.

:root { --icon: theme(colors.slate.500); }
.dark { --icon: theme(colors.slate.300); }
.text-token-icon { color: var(--icon); }

// One class themes every icon, light and dark:
<nav className="text-token-icon">
  <SearchIcon className="h-5 w-5" />
  <BellIcon   className="h-5 w-5" />
</nav>

A thin Icon wrapper to supply the missing size prop

The converter emits no size prop. If your design system speaks in size tokens, wrap once and map tokens to width/height — keeping every per-icon component untouched.

const SIZES = { sm: 16, md: 20, lg: 24 } as const;
type Props = React.SVGProps<SVGSVGElement> & { icon: React.FC<React.SVGProps<SVGSVGElement>>; size?: keyof typeof SIZES };

export function Icon({ icon: Glyph, size = 'md', ...rest }: Props) {
  const px = SIZES[size];
  return <Glyph width={px} height={px} aria-hidden {...rest} />;
}

// Usage:
<Icon icon={SearchIcon} size="lg" className="text-token-icon" />

Namespacing ids so two of the same icon don't collide

The converter keeps ids verbatim. A masked/gradient icon rendered twice references the first instance's defs. Namespace ids per component in your regeneration script.

// Before (two <LogoIcon/> on one page → broken second mask):
<clipPath id="clip0">…
fill="url(#paint0_linear)"

// Regeneration post-pass output, ids prefixed per component:
<clipPath id="LogoIcon-clip0">…
fill="url(#LogoIcon-paint0_linear)"
// references rewritten to match → both instances render correctly.

Regeneration when Figma changes (keep design ↔ code in sync)

A repeatable pipeline so a design update is a script run, not manual surgery. Export → normalise → convert → namespace ids → barrel → type-check.

# 1. Export changed icons from Figma to src/assets/icons/
# 2. Normalise: scrub metadata + minify + currentColor
# 3. Convert each to TSX via the local runner (engine-mode, stays local)
# 4. Post-pass: namespace ids, fix any inline styles
# 5. Regenerate src/components/icons/index.ts barrel
# 6. npx tsc --noEmit && run visual snapshots
# Wire steps 2-6 into one npm script: "icons:build"

Converted icons are pure renderers with no hooks or handlers, so they're valid Server Components. Slapping 'use client' on each one needlessly ships client JS for static glyphs and can pull a server tree into the client bundle. Keep icons server-rendered; only the interactive wrapper (a button with onClick) needs the client boundary.

Figma often exports fill="#1F2937". After conversion that icon stays fixed grey and never follows your dark-mode token. The converter preserves colours; it doesn't tokenise them. Normalise to currentColor with svg-to-tailwind (current mode) or svg-hex-swapper before converting, then theme with one text-… class.

Masks, gradients, and clip-paths use ids the converter keeps verbatim. Render the icon twice and the second instance references the first's defs, so it renders wrong (missing clip, flat gradient). Namespace ids per component in your build pipeline, or use svg-sprite-builder for heavily-repeated icons.

Some exporters emit style="…" on elements. The converter passes the string through and React throws because style must be an object. Either configure the export to use presentation attributes, strip styles in the normalise step, or add a style-string-to-object post-pass before committing.

The converter emits no size prop — sizing comes through {...props}/className. Standardise on utility classes (h-5 w-5) or a thin <Icon size=…> wrapper that maps tokens to width/height. Don't wait for the converter to add it; design the convention.

A single index.ts re-exporting hundreds of icons is convenient but can prevent some bundlers from dropping unused icons, especially with side-effectful modules. Keep each icon in its own module, mark the package side-effect-free, and import from specific modules when bundle size is critical.

The converter does not wrap components in forwardRef, so libraries that need a ref to the SVG element won't get one. Wrap the converted component in React.forwardRef yourself, or generate that subset with @svgr (ref: true). Most icons don't need refs, so apply this only where required.

Two source files PascalCasing to the same name (menu.svg and Menu.svg) produce duplicate export const Menu, breaking the barrel. Enforce unique, validated names in the regeneration script and fail the build on collision rather than shipping a shadowed export.

If your set includes filter primitives (flood-color, lighting-color), those attributes aren't on the rename list and React warns. Add the renames to your post-pass, or keep filter-heavy art as external <img>/sprite assets rather than inline components.

An icon without a viewBox won't scale predictably when you set width/height or CSS sizes on the component. The converter doesn't synthesise a viewBox. Fix it at the source (or with svg-viewbox-fixer) before converting so the icon scales cleanly in the system.