feat: allow .svg files to be inlined #2909
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -8,6 +8,7 @@ import { cleanUrl } from '../utils' | |
| import { FS_PREFIX } from '../constants' | ||
| import { PluginContext, RenderedChunk } from 'rollup' | ||
| import MagicString from 'magic-string' | ||
| import svgToTinyDataUri from 'mini-svg-data-uri' | ||
| import { createHash } from 'crypto' | ||
|
|
||
| export const assetUrlRE = /__VITE_ASSET__([a-z\d]{8})__(?:\$_(.*?)__)?/g | ||
|
|
@@ -207,12 +208,18 @@ async function fileToBuiltUrl( | |
|
|
||
| let url | ||
| if ( | ||
| (config.build.lib || | ||
| Buffer.byteLength(content) < config.build.assetsInlineLimit) && | ||
| hash == null | ||
| ) { | ||
| // svgs can be inlined without base64 | ||
| url = file.endsWith('.svg') | ||
|
There was a problem hiding this comment. An earlier issue I saw mentioned using Has It doesn't seem so looking at There was a problem hiding this comment. While There was a problem hiding this comment. I used plain There was a problem hiding this comment.
It shouldn't be common no. Depends if you want to avoid it ever being an issue for users that do though. Not a big deal, worse that happens is it gets encoded as base64 instead and if that bothers/confuses a user, they raise an issue and someone can point out lowercase extension is only supported or someone adds the fix by lowercasing the filename (only for checking the extension).
I don't know what you mean here? You just use url = file.toLowerCase().endsWith('.svg') |
||
| ? // The only difference between the default method and `toSrcset` is that | ||
| // the latter encodes spaces as `%20`, so it's safer to always use it | ||
| // to support `srcset` use-case even when svg is imported into JavaScript | ||
| svgToTinyDataUri.toSrcset(content.toString()) | ||
| : // base64 inlined as a string | ||
| `data:${mime.getType(file)};base64,${content.toString('base64')}` | ||
| } else { | ||
| // emit as asset | ||
| // rollup supports `import.meta.ROLLUP_FILE_URL_*`, but it generates code | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Where does the
%3ecome from, and why only in build mode?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@aleclarson it's the url-encoded version of
>so the string being matched issvg>#icon-heart-view, whereas the non-build mode version hasn't had the SVG inlined, thus is still referencing the SVG by filename, instead of the closingsvgtag, it's thesvgextension.I'm assuming this was tested in a browser that it actually works with the fragment and not just to pass the test though. I know that
#needs to be url-encoded for inlining SVG usually, but perhaps it's not meant to be when appending the fragment identifier after the inlined SVG like you would append it after a file extension? I've never used fragments, but I'm interested to know if that works as intended.