![Create React App Officially Deprecated Amid React 19 Compatibility Issues](https://cdn.sanity.io/images/cgdhsj6q/production/04fa08cf844d798abc0e1a6391c129363cc7e2ab-1024x1024.webp?w=400&fit=max&auto=format)
Security News
Create React App Officially Deprecated Amid React 19 Compatibility Issues
Create React App is officially deprecated due to React 19 issues and lack of maintenance—developers should switch to Vite or other modern alternatives.
sass-inline-svg-utf8
Advanced tools
Inline SVGs in your CSS as html-encoded UTF-8, string replacement included.
#sass-inline-svg-utf8
Inline SVGs in your CSS as html-encoded UTF-8 with node-sass.
Inlining is good because fewer requests, html-encoded is good for SVG because it is smaller than base64 (by about 30% on average).
String replacement is good because you can use 'variables' in your SVG source files and replace them on a per-inlined-instance basis. Use case? You need a white, a black, and a blue arrow icon, and can create them on the fly when inling from a single source file. Good because if the arrow needs to be changed, you only have to change on file, not three.
npm install --save-dev sass-inline-svg-utf8
var sass = require('node-sass');
var sassInlineSVG = require('sass-inline-svg-utf8');
sass.render({
functions: sassInlineSVG(),
file: file,
outfile: outfile
}, function(error, result) {
/* Your code here */
});
In your Sass:
.myClass {
background-image: inline-svg('./images/logo.svg');
}
For optimal results and minimal filesize, run your SVGs through SVGO first (Actually, I'm on the fence whether to include SVGO optimization by default when inlining, but I’m not sure because of various settings/complexity). If you have a strong opinion on that, let’s dicuss here.
In your SVG source, you can use variable strings to replace when inlining:
<path fill="fillcolor" […] />
In your Sass, you can pass a map of variables to replace as a second parameter:
.myClass {
background-image: inline-svg('./images/arrow.svg', { fillcolor: '#000000'});
}
This will replace all occurences of fillcolor
in the SVG file with #000000
in the inlined SVG.
If you want to use $
-prepended variable names to match your Sass variables, quote them in the Sass map like { '$fillcolor': '#000000' }
.
This will result in (not html encoded here for readability):
<path fill="#000000" […] />
So to create three instances of the same SVG source with different fill colors in your CSS:
.red-arrow {
background-image: inline-svg( './images/arrow.svg', ( fillcolor: 'red'));
}
.blue-arrow {
background-image: inline-svg( './images/arrow.svg', ( fillcolor: 'blue'));
}
.black-arrow {
background-image: inline-svg( './images/arrow.svg', ( fillcolor: 'black'));
}
To use non-named colors like hex, rgba etc., these need to be passed as a quoted string (this is down to the current behavior of node-sass/libsass):
.white-arrow {
background-image: inline-svg( './images/arrow.svg', ( fillcolor: '#fff'));
}
Whn using variables that may contain colors, these need to be evaluated to be on the safe side:
.custom-arrow {
background-image: inline-svg( './images/arrow.svg', ( fillcolor: #{$custom-color}));
}
I have opened this issue with node-sass to make the quoting/evaluating unnecessary (fingers crossed…)
FAQs
Inline SVGs in your CSS as html-encoded UTF-8, string replacement included.
We found that sass-inline-svg-utf8 demonstrated a not healthy version release cadence and project activity because the last version was released a year ago. It has 1 open source maintainer collaborating on the project.
Did you know?
Socket for GitHub automatically highlights issues in each pull request and monitors the health of all your open source dependencies. Discover the contents of your packages and block harmful activity before you install or update your dependencies.
Security News
Create React App is officially deprecated due to React 19 issues and lack of maintenance—developers should switch to Vite or other modern alternatives.
Security News
Oracle seeks to dismiss fraud claims in the JavaScript trademark dispute, delaying the case and avoiding questions about its right to the name.
Security News
The Linux Foundation is warning open source developers that compliance with global sanctions is mandatory, highlighting legal risks and restrictions on contributions.