Generate a .svg file instead of an embedded SVG tag

[Ariane-B]

Is it possible to use this plugin in a way where a .svg asset file for the sprite is generated and it can be <use>d from there, instead of directly embedding an <svg> tag in the page's DOM?

If not, is it something you'd consider? The separate file approach can better exploit visitors' browsers' cache, so I think it'd be all-around better.

[adamrobinson]

I would also love this option

[pivanov]

Same here ... this will help to reduce the bundle size and also will give us the option to cache the sprites. One more cool thing is that if we have a few sprites some of them could be accessed only when we need (the user will fetch/prefetch the sprite only when is needed).

+1 from me too

[felixranesberger]

I'm not sure, why this would be an issue. The SVG code that is used to inject the sprite into the DOM can be split into a better cacheable JS file by using dynamic imports. So using a sprite file isn't a huge benefit, because it doesn't make much of a difference if you load a sprite icon, instead of using JS to inject it.

[felixranesberger]

You can replace

import 'virtual:svg-icons-register'

with

import('virtual:svg-icons-register')

This will cause Vite to split the sprite injecting code into its own file, which will then be async loaded.

[Ariane-B]

I'm not sure, why this would be an issue. The SVG code that is used to inject the sprite into the DOM can be split into a better cacheable JS file by using dynamic imports. So using a sprite file isn't a huge benefit, because it doesn't make much of a difference if you load a sprite icon, instead of using JS to inject it.

Well for one it's hella polluting if you just start putting every icon straight into your HTML. Even before considering any practical benefits, doesn't it irk you?

Anyway, for debugging purposes, it's really helpful to have a final svg file somewhere that you can open and look at instead of it all being imaginary magic code that appears in the HTML.

You can replace

import 'virtual:svg-icons-register'

with

import('virtual:svg-icons-register')

This will cause Vite to split the sprite injecting code into its own file, which will then be lazyloaded.

Isn't an import with parentheses a dynamic import that's executed at runtime? That sounds kinda non-ideal, doesn't it?

Also if the difference between a file and a non-file is whether it's a dynamic import or not, isn't that a bit of a problem? Dynamic vs actual file are different needs, and it's pretty counter-intuitive that the parentheses change everything.

Also, can you determine the file name?

But even before all that, why does it have to be a side-effect import? I may be misunderstanding something, but I'd have expected it to be, like, import iconSprite from 'my/folder' or something like that, and then have an object representation of my sprite to play with. Side effect imports are a bit uncomfortable because you can't decide yourself where to put the thing/what to do with it exactly.

It would be hella nice to be able to add, stuff to my component that depends on the svg's filename or aspect ratio or something like that.

[felixranesberger]

I think you're right, especially since the injected SVG nodes are inflating the DOM quite a lot.

[shadura]

Any updates?

[Alfred-wen]

hello, any updates?

[felixranesberger]

I think someone of the community has to provide a pull request, so that this issue can be resolved. This vite plugin could help when implementing a solution. The functionality should probably be opt-in, as it would be a breaking change.