Svgr: Can't set SVGO options

[ThiagoFacchini]

🐛 Bug Report

I need basically need to keep the svg viewBox when using @svgr/webpack.

I tried every piece of documentation I found spread among web pages and tickets previously opened in git.

svgr/webpack version: 5.1.0
webpack version: 4.29.6

To Reproduce

Configurations I tried:

webpack config file:

{
   test: /\.svg$/,
   use: [{
      loader: '@svgr/webpack',
      options: {
         svgoConfig: {
            plugins: [{
               removeViewBox: false
            }]
         }
      }
   }, 'file-loader']
},

in .svgorc:

plugins:
    - removeViewBox: false

with the webpack config file I tried inside my application:
import svgfileurl , { ReactComponent as svgFile } from 'whatevever.svg'

both svgfileurl and svgFile return a function which returns a reactComponent

Expected behavior

For the viewBox attribute to be preserved

Any ideas?

[open-collective-bot[bot]]

Hey @ThiagoFacchini :wave:,
Thank you for opening an issue. We'll get back to you as soon as we can.
Please, consider supporting us on Open Collective. We give a special attention to issues opened by backers.
If you use SVGR at work, you can also ask your company to sponsor us :heart:.

[gregberge]

Use svgo in option instead of svgoConfig.

[ThiagoFacchini]

Thanks for your suggestion @gregberge, but it didn't work either.

Here's how I tried:

{
   test: /\.svg$/,
   use: [{
      loader: '@svgr/webpack',
      options: {
         svgo: {
            plugins: [{
               removeViewBox: false
            }]
         }
      }
   }]
},

I only get <svg> in the dom.

Also double checked my svg, which looks like:
<svg id="Layer_1" data-name="Layer 1" xmlns="http://www.w3.org/2000/svg" viewBox="0 0 26.82 42.81">

What else could be causing this annoying issue?

[gregberge]

I don't know it needs to be investigated.

[ThiagoFacchini]

Extra information:

I downgraded the library to 4.3.3 and svgo and svgoConfig options don't work either.

[gregberge]

You should try to investigate it by adding some console.log to see where is the problem. The code of SVGR is pretty simple (for SVGO chaining).

[kakadiadarpan]

I'm on version 5.2.0 of @svgr/webpack, and I have a .svgo.yml file which contains the following config:

# .svgo.yml
plugins:
  - removeViewBox: false

This works in development mode and does not remove the viewBox attribute from svg, but it removes that attribute during the production mode. Not sure why. 🤔

[kbouchard]

Hey guys, I just went through the same issue on v5.2.0 . After trying a lot of things, nothing worked.

So I downgraded to 4.3.3 , using the config below and it's working for me now.

// SVG: imported and rendered inline from JS files
svgInline: {
  test: /\.svg(\?v=\d+\.\d+\.\d+)?$/,
  issuer: {
    // Only inlining svg loaded from jsx? files
    test: /\.jsx?$/,
  },
  use: [
    'babel-loader',
    {
      loader: '@svgr/webpack',
      /*
        Using .svgo.yml for now to prevent the removeViewBox issue
      */
      options: {
        svgoConfig: {
          // See: https://github.com/svg/svgo#what-it-can-do
          // Important! We need to stick to @svgr/weback v4.3.3 to prevent an issue
          // where removeViewBox is not applied (still not fixed in 5.2.0).
          plugins: [{
            removeViewBox: false,
            removeTitle: false,
            convertShapeToPath: false,
            mergePaths: false,
          }],
        }
      },
    },
  ],
},

[yb7272838q]

@kbouchard thanks

[ghostd]

Ok, after some invastigation i found how to make it work.

This does not work:

  const svgoConfig = {
    plugins: [
      {
        convertColors: {
          currentColor: true,
        },
        prefixIds: {
          prefix: componentName
        }
      },
    ],
  };

This works (note each plugin settings must be in its own object)

  const svgoConfig = {
    plugins: [
      {
        convertColors: {
          currentColor: true,
        }
      }, {
        prefixIds: {
          prefix: componentName
        }
      },
    ],
  };

Maybe we could ehance the extendPlugins function to handle this.

[gregberge]

@ghostd thanks for the investigation! Of course we should being able to handle it. Could you (or anyone else) submit a PR please?