If you are reporting a bug or requesting support, start here:
I updated the storybook in my project and found out that SVG fonts are not loaded correctly by the default wepack.config.js.
I noticed that .svg extension was removed from the loader that deals with fonts in the #3221 commit:
{
test: /\.(ico|jpg|jpeg|png|gif|eot|otf|webp|ttf|woff|woff2)(\?.*)?$/,
loader: require.resolve('file-loader'),
query: {
name: 'static/media/[name].[hash:8].[ext]'
}
}
and svg-url-loader was added:
{
test: /\.svg$/,
loader: require.resolve('svg-url-loader')
},
The problem is that when there is a third-party components are loaded from node_modules, such as FontAwesome, the .svg in the css gets converted, causing an error in the css:
@font-face {
font-family: 'FontAwesome';
src: url(/static/media/fontawesome-webfont.674f50d2.eot);
src: url(/static/media/fontawesome-webfont.674f50d2.eot?#iefix&v=4.7.0) format('embedded-opentype'),
url(/static/media/fontawesome-webfont.af7ae505.woff2) format('woff2'),
url(/static/media/fontawesome-webfont.fee66e71.woff) format('woff'),
url(/static/media/fontawesome-webfont.b06871f2.ttf) format('truetype'),
url("data:image/svg+xml,%3C?xml version='1.0' standalone='no'?%3E %3C!DOCTYPE svg PUBLIC '-//W3C//DTD SVG 1.1//EN' 'http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd' %3E %3Csvg%3E %3Cmetadata%3E Created by FontForge 20120731 at ...

It should be:
@font-face {
font-family: 'FontAwesome';
src: url(/static/media/fontawesome-webfont.674f50d2.eot);
src: url(/static/media/fontawesome-webfont.674f50d2.eot?#iefix&v=4.7.0) format('embedded-opentype'),
url(/static/media/fontawesome-webfont.af7ae505.woff2) format('woff2'),
url(/static/media/fontawesome-webfont.fee66e71.woff) format('woff'),
url(/static/media/fontawesome-webfont.b06871f2.ttf) format('truetype'),
url(/static/media/fontawesome-webfont.912ec66d.svg#fontawesomeregular)
The solution would be removing svg-url-loader from the default webpack.config.js and adding back the |svg test in this line.
does using url-loader not have this issue?
@danielduan This issue persists even with url-loader
@emiyake it's not caused by that PR then. while we try to provide a sensible webpack configuration, it's impossible to support everything. your best bet is to use the Full Control Mode and remove the svg-url-loader entry
same problem as https://github.com/storybooks/storybook/issues/3450
I see. Wouldn't it make sense not to add svg-url-loader in the default configuration and add it with Extended Control Mode when needed, instead of forcing developers to remove it from the baseConfig?
My understanding of basic configuration is to have a minimum support and we should add additional loaders according to the project needs (just like when we add loaders such as typescript).
The current approach causes incompatibility with other packages, which could be avoided.
What doesn't make sense to me is to create a full control webpack to remove things, instead of adding new loaders.
Makes sense to me @emiyake
I'm having a similar issue with Semantic UI...
"@storybook/react": "^4.0.0-alpha.2" will break all the FontAwesome icons baked into Semantic UI. It's affecting the npm package "semantic-ui-css" as well as a local version of the Semantic library I've built.
@anthonymetzler https://gist.github.com/emiyake/a1302eeca331cceaf129789bb0a6c216
Hi everyone! Seems like there hasn't been much going on in this issue lately. If there are still questions, comments, or bugs, please feel free to continue the discussion. Unfortunately, we don't have time to get to every issue. We are always open to contributions so please send us a pull request if you would like to help. Inactive issues will be closed after 30 days. Thanks!
Hey there, it's me again! I am going close this issue to help our maintainers focus on the current development roadmap instead. If the issue mentioned is still a concern, please open a new ticket and mention this old one. Cheers and thanks for using Storybook!
Most helpful comment
I see. Wouldn't it make sense not to add
svg-url-loaderin the default configuration and add it withExtended Control Modewhen needed, instead of forcing developers to remove it from the baseConfig?My understanding of basic configuration is to have a minimum support and we should add additional loaders according to the project needs (just like when we add loaders such as typescript).
The current approach causes incompatibility with other packages, which could be avoided.
What doesn't make sense to me is to create a
full controlwebpack to remove things, instead of adding new loaders.