@svgr/core

@svgr/core is the programmatic engine behind SVGR, the universal SVG-to-React transform used across the ecosystem’s CLI, webpack loader, and Rollup plugin. It exposes a single transform() (and synchronous transform.sync()) function that takes raw SVG source and a config object and returns compilable JSX or TSX source, with no plugins bundled by default so consumers opt into exactly the processing they need.

Under the hood it wires together cosmiconfig-based .svgrrc resolution, a Babel-based JSX code generator (@svgr/babel-preset), and an ordered plugin pipeline — typically @svgr/plugin-svgo for SVG optimization, @svgr/plugin-jsx for component generation, and @svgr/plugin-prettier for output formatting. Because the transform is just a function over strings, it slots into any build tool: it’s the shared core that @svgr/webpack, @svgr/rollup, and @svgr/cli all call internally, and it can be used directly in custom Node scripts or build pipelines that need SVG-to-component conversion without pulling in a specific bundler integration.

What You Get

• A transform/transform.sync API that turns an SVG string into React (or React Native) component source with a single function call
• Automatic .svgrrc/svgr.config.js discovery via cosmiconfig, so project-wide defaults apply without repeating options at every call site
• A composable plugin system (@svgr/plugin-svgo, @svgr/plugin-jsx, @svgr/plugin-prettier) that lets consumers pick exactly which processing steps run
• Rich per-call configuration: TypeScript output, ref forwarding, memo wrapping, title/desc props, icon sizing, attribute replacement, and custom JSX templates
• The shared foundation reused by @svgr/webpack, @svgr/rollup, and @svgr/cli, so behavior stays consistent across every SVGR integration

Common Use Cases

• Writing a custom build step or codemod that batch-converts a directory of SVG icon files into React components
• Building a bundler plugin or loader for a tool SVGR doesn’t already integrate with, by calling transform() directly
• Generating typed React Native SVG components from a shared icon set for cross-platform apps
• Embedding SVG-to-JSX conversion inside a design-system tool or Storybook/asset pipeline that needs programmatic control over output

Under The Hood

Architecture The library is a thin, deliberately linear pipeline: transform() in packages/core/src/transform.ts first resolves configuration by merging DEFAULT_CONFIG with caller-supplied options and any .svgrrc file found via cosmiconfig (config.ts), then expands the call’s state (deriving a PascalCase componentName from the file path when one isn’t given, in state.ts), and finally folds the SVG string through an ordered array of plugins resolved by plugins.ts — each plugin is just (code, config, state) => string, so the entire transform is a reduce over pure string-to-string functions with no shared mutable state between steps. This makes the core trivially embeddable: @svgr/webpack, @svgr/rollup, and @svgr/cli all just call the same transform/transform.sync entry point with different default plugin lists (via state.caller.defaultPlugins), so adding a new build-tool integration to the monorepo means writing an adapter, not touching the core.

Tech Stack Written in TypeScript and built with Rollup (build/rollup.config.mjs) into CJS output with generated .d.ts types. It depends on @babel/core and the workspace’s own @svgr/babel-preset for the actual SVG-to-JSX code generation, cosmiconfig for .svgrrc/svgr.config.js discovery, plus small utilities (camelcase, snake-case) for name derivation. The package lives in a pnpm/Lerna workspace monorepo alongside the other SVGR packages, versioned and published together.

Code Quality The package has direct unit test coverage for its three core modules — transform.test.ts, config.test.ts, and plugins.test.ts — using Jest with snapshot assertions for generated component output, and each async API is mirrored by an explicit sync-mode test via a describe.each(['sync', 'async']) pattern. The whole monorepo runs a shared ESLint config (@typescript-eslint, eslint-plugin-react) and Prettier check in CI, and CI itself runs the test suite across a matrix of Node 14/16/18/19, giving reasonable confidence in cross-version compatibility. Types are used throughout the public API surface (Config, State, Plugin), though a few internal spots opt out of strict typing with any and @ts-ignore.

API Design The public surface is intentionally minimal: two functions (transform, transform.sync) plus a handful of exported types, with every option living in one Config interface documented inline via TypeScript types. Because no plugins are bundled by default, first-time use requires explicitly listing plugins: ['@svgr/plugin-svgo', '@svgr/plugin-jsx', '@svgr/plugin-prettier'] — a small amount of upfront boilerplate compared to higher-level entry points like @svgr/cli, but it keeps the core dependency-free for consumers who only need a subset of the pipeline.