You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I would like the ability to import SVGs and use them directly as components. This is useful for iconography and complex SVG animations, because the SVG will end up as a React component somehow, someway anyways.
Describe the solution you'd like
Integrate SVGR directly into Next.js's webpack configuration and support the ability to import an SVG directly as a component and update the type definitions for '*.svg' imports.
Even if that sacrifice didn't exist, the type declaration for '*.svg' imports has to be overridden with patch-package as there's no way to ignore type declarations from one dependency, file, or module. The alternatives are not great.
The text was updated successfully, but these errors were encountered:
Describe the feature you'd like to request
I would like the ability to import SVGs and use them directly as components. This is useful for iconography and complex SVG animations, because the SVG will end up as a React component somehow, someway anyways.
Describe the solution you'd like
Integrate SVGR directly into Next.js's webpack configuration and support the ability to import an SVG directly as a component and update the type definitions for
'*.svg'
imports.SVGR has long supported the ability to peacefully coexist with file-loader and url-loader usages by using named imports. So, there exists a way to integrate this without a breaking change and in keeping with standard practice.
Describe alternatives you've considered
Before v11, I was able to use https://github.com/newhighsco/next-plugin-svgr (and there many other simple ways to customize the webpack configuration to leverage the tool. You're able to now, but not without sacrificing upgrades.
Even if that sacrifice didn't exist, the type declaration for
'*.svg'
imports has to be overridden withpatch-package
as there's no way to ignore type declarations from one dependency, file, or module. The alternatives are not great.The text was updated successfully, but these errors were encountered: