Gatsby: Svg Loading when using `gatsby develop` but not `gatsby serve`

[laurieontech]

Description

I have an svg that I'm referencing directly in my css. I can see it render in the gatsby develop view of my site, but not when I build and serve.

Steps to reproduce

This is the repository and the specific line in question: https://github.com/lstar19/website-gatsby/blob/87f183ff4a3d5d785cb2dd47a3983aa22d4a5642/src/assets/css/test.css#L327

Run gatsby develop and on the http://localhost:8000/blog/ page, each blog post block will have subtle lines.

Run gatsby build, gatsby serve and navigate to http://localhost:9000/blog/. The lines will no longer appear.

Expected result

These pages should be the same.

Actual result

The svg only appears in develop mode.

Environment

System:
OS: macOS 10.14.4
CPU: (8) x64 Intel(R) Core(TM) i7-4980HQ CPU @ 2.80GHz
Shell: 5.3 - /bin/zsh
Binaries:
Node: 11.0.0 - ~/.nvm/versions/node/v11.0.0/bin/node
Yarn: 1.17.0 - /usr/local/bin/yarn
npm: 6.4.1 - ~/.nvm/versions/node/v11.0.0/bin/npm
Languages:
Python: 2.7.12 - /usr/local/bin/python
Browsers:
Chrome: 75.0.3770.100
Firefox: 49.0.1
Safari: 12.1
npmPackages:
gatsby: ^2.13.12 => 2.13.12
gatsby-background-image: ^0.2.74 => 0.2.74
gatsby-image: ^2.2.4 => 2.2.4
gatsby-plugin-google-gtag: ^1.1.1 => 1.1.1
gatsby-plugin-gtag: ^1.0.11 => 1.0.11
gatsby-plugin-manifest: ^2.2.1 => 2.2.1
gatsby-plugin-offline: ^2.2.1 => 2.2.1
gatsby-plugin-react-helmet: ^3.1.0 => 3.1.0
gatsby-plugin-react-svg: ^2.1.1 => 2.1.1
gatsby-plugin-sass: ^2.1.0 => 2.1.0
gatsby-plugin-sharp: ^2.2.3 => 2.2.3
gatsby-source-filesystem: ^2.1.3 => 2.1.3
gatsby-transformer-remark: ^2.6.1 => 2.6.1
gatsby-transformer-sharp: ^2.2.1 => 2.2.1
gatsby-transformer-yaml: ^2.2.0 => 2.2.0
npmGlobalPackages:
gatsby-cli: 2.4.17

[pieh]

Ok, this is weird one:
In both cases we inline svg image with base64 - but they are different.

In develop we, after decoding it back we get (for first of svgs, but seems same thing applies):

<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" width="500px" height="500px" viewBox="0 0 500 500" zoomAndPan="disable">
    <style type="text/css"><![CDATA[
        line
        {
            stroke: rgba(255,255,255,0.2);
            stroke-width: 1px;
        }
    ]]></style>
    <line x1="0" y1="0" x2="500" y2="500"/>
    <line x1="0" y1="60" x2="440" y2="500"/>
    <line x1="0" y1="120" x2="380" y2="500"/>
    <line x1="0" y1="180" x2="320" y2="500"/>
    <line x1="0" y1="240" x2="260" y2="500"/>
    <line x1="0" y1="300" x2="200" y2="500"/>
    <line x1="0" y1="360" x2="140" y2="500"/>
    <line x1="0" y1="420" x2="80" y2="500"/>
</svg>

Which matches what is in used svg file ( https://github.com/lstar19/website-gatsby/blob/87f183ff4a3d5d785cb2dd47a3983aa22d4a5642/src/assets/css/images/dark-bl.svg?short_path=1b0fa5a )

In build we get:

<svg xmlns="http://www.w3.org/2000/svg" width="500" height="500" zoomAndPan="disable"><style>line{stroke:rgba(255,255,255,.2);stroke-width:1px}</style><path d="M0 0l500 500M0 60l440 440M0 120l380 380M0 180l320 320M0 240l260 260M0 300l200 200M0 360l140 140M0 420l80 80"/></svg>

Which seems like some transformation/optimization is applied, but I couldn't immediately find what's doing that. In any case <line>s are converted to single path, but style rule still tries to apply to line. This makes it look like svg is not there, but it's there - only some optimization essentially broke it

I'll investigate more, just wanted to leave quick reply

[laurieontech]

Thanks for the reply! That's definitely a little trippy.

[pieh]

Found primary offender - https://github.com/NMFR/optimize-css-assets-webpack-plugin we use in production builds seems to cause this. TBD if we can force it to not mess with svg

[pieh]

I opened PR ( https://github.com/gatsbyjs/gatsby/pull/15636 ) that fixes this specific issue, but there might be more discussion there. It seems like trying to use SVGO (dependency of dependency of NMFR/optimize-css-assets-webpack-plugin ) automatically proves to cause a lot of headaches and maybe SVGO should just be completely disabled (instead of targetting specifc optim in svgo like I did initially)