[evoactivity]

Each target now exports its component type as SvgComponent, so apps can type a variable, prop or config field that holds an SVG import without writing out the type.

import type { SvgComponent } from '@svg-jar/plugin/types/ember';

Changes

• Added client/<target>-types.d.ts for all 7 targets, published at @svg-jar/plugin/types/<target>. The DOM file also exports SvgOptions.
• The client/<target>.d.ts files stay ambient, so the tsconfig "types" setup works as before. A .d.ts file with an export becomes a module, and its declare module '*.svg' blocks then stop applying, so the named type lives in a separate file. Importing the type has no global effect, and the *.svg declarations still come from the tsconfig entry.
• The DOM client no longer declares a global SvgOptions interface.
• runtime/react.ts is now typed against @types/react, in the same way the Preact, Vue and Solid runtimes use their framework types. Nothing changes when it runs.
• The README has a new "Typing an icon" section with Ember first, and the custom declaration example uses SvgComponent.

Dependencies

• Added @glint/template and @types/react as plugin devDependencies, so the client types resolve inside this workspace. Before this, React SVG imports were typed any here because @types/react could not be found from the plugin folder.
• Added @glint/template and typescript to the Ember test project.

Tests

Each test project has a svg-types.ts that annotates plain, ?unsafe-inline and ?sprite=shapes imports with SvgComponent, plus a @ts-expect-error check that fails if an import is typed any. Each project's custom sprite declaration now uses the named type. The Ember test project has a new tsconfig.json and typecheck script, so the CI build job's pnpm typecheck covers it.

🤖 Generated with Claude Code