SVGR exception with CDATA inside <style/> tag

[kodidu]

Hello!

My application to design SVG uses CDATA inside the <style/> section.
All tested browsers open this SVG without issues:

<svg xmlns="http://www.w3.org/2000/svg" xml:space="preserve" width="960px" height="560px" version="1.1" viewBox="0 0 960 560">
 <defs>
  <style type="text/css">
   <![CDATA[
    .fnt0 {font-weight:normal;font-size:39px;font-family:'Arial'}
   ]]>
  </style>
 </defs>
 <g id="XO">
  <metadata id="Layer"/>
  <text x="751" y="104" id="Temp" class="fnt0">25.0°C</text>
 </g>
</svg>

But SVGR fails to convert the SVG if i disable SVGO:

PS src\application\components> npx  @svgr/cli --icon --no-svgo -d .\ .\svg\cdata.svg
node_modules\@svgr\cli\lib\index.js:162
    throw error;
    ^
Error: Expected node, got `
    .fnt0 {font-weight:normal;font-size:39px;font-family:'Arial'}
   `
    at one (node_modules\@svgr\cli\node_modules\@svgr\hast-util-to-babel-ast\lib\one.js:12:11)
    at all (node_modules\@svgr\cli\node_modules\@svgr\hast-util-to-babel-ast\lib\all.js:20:37)
    at element (node_modules\@svgr\cli\node_modules\@svgr\hast-util-to-babel-ast\lib\handlers.js:51:37)
    at one (node_modules\@svgr\cli\node_modules\@svgr\hast-util-to-babel-ast\lib\one.js:19:10)
    at all (node_modules\@svgr\cli\node_modules\@svgr\hast-util-to-babel-ast\lib\all.js:20:37)
    at element (node_modules\@svgr\cli\node_modules\@svgr\hast-util-to-babel-ast\lib\handlers.js:51:37)
    at one (node_modules\@svgr\cli\node_modules\@svgr\hast-util-to-babel-ast\lib\one.js:19:10)
    at all (node_modules\@svgr\cli\node_modules\@svgr\hast-util-to-babel-ast\lib\all.js:20:37)
    at element (node_modules\@svgr\cli\node_modules\@svgr\hast-util-to-babel-ast\lib\handlers.js:51:37)
    at one (node_modules\@svgr\cli\node_modules\@svgr\hast-util-to-babel-ast\lib\one.js:19:10)
PS src\application\components> 

So maybe SVGO parses the CDATA section without issues but if SVGR parses the SVG directly it fails.
If i simply remove <![CDATA[`` and ]]` SVGO and SVGR have no issues.

[open-collective-bot]

Hey @kodidu 👋,
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 ❤️.

[flo-sch]

I am also facing that issue when trying to load animated SVGs (containing <script> elements), downloaded from https://www.svgator.com/

(Tried using both @svgr/webpack and @svgr/cli)

I think the issue comes from @svgr/core more than svgo in that case, since I managed to successfully have those icons render on https://jakearchibald.github.io/svgomg/, after turning off a few SVGO options.

With my config, the plugins order (called by @svgr/core.sync) is:

1. svgoPlugin
2. jsxPlugin
3. prettierPlugin

And I can confirm that the first call to @svgr/plugin-svgo passes.

The error is thrown by @svgr/hast-util-to-babel-ast (sorry if that seems obvious, I do not know the API here 🤷‍♂️): @svgr/hast-util-to-babel-ast.one:

@svgr/cli.command
└ @svgr/cli.dirCommand
└─ @svgr/cli.util.convertFile
└── @svgr/cli.util.convert
└─── @svgr/core.convert.sync
└──── @svgr/core.sync (looping through each plugin)
└───── @svgr/plugin-jsx.jsxPlugin
└────── @svgr/hast-util-to-babel-ast
└─────── @svgr/hast-util-to-babel-ast.one

For what it's worth, here is the shape of the parsed hastTree sent to hastToBabelAst()

{
  "type": "root",
  "children": [
    {
      "type": "element",
      "tagName": "svg",
      "properties": {
        "xmlns": "http://www.w3.org/2000/svg",
        "xmlns:xlink": "http://www.w3.org/1999/xlink",
        "id": "/* ... */",
        "shape-rendering": "geometricPrecision",
        "text-rendering": "geometricPrecision",
        "viewBox": "0 0 64 64"
      },
      "children": [
        {
          "type": "element",
          "tagName": "path",
          "properties": {
            "id": "/* ... */",
            "fill": "#FFF",
            "fill-rule": "evenodd",
            "stroke": "none",
            "stroke-width": 1,
            "d": "/* ... */",
            "clip-rule": "evenodd",
            "transform": "/* ... */"
          },
          "children": []
        },
        // ... a bunch of other "path", those are handled correctly
        // then comes the script node crashing it
        {
          "type": "element",
          "tagName": "script",
          "properties": {},
          "children": [
            "!function(t,n){/*...*/}"
          ]
        }
      ],
      "metadata": ""
    }
  ]
}

Perhaps the solution would be to create a handler for scripts/styles inside hast-util-to-babel-ast, or even on a higher level to have those ignored?

I would love to contribute, but I need some guidance how to approach it (I never played with the babel API directly) 😊

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[ginnymin]

Is it possible for this issue to be looked into? Ran into this when upgrading to CRA5

[PhilipWee]

I'm gonna put some of my investigation results here

1. This seems to be a CRA 5 issue. Because CRA 5 uses SVGR 5.5.0
2. A simple test case with CDATA passes on the latest version (Ran in gitpod as recommended in CONTRIBUTING.md)
   it('Handles CDATA', () => { const code = <script> test() </script>

`

expect(typeof transform(code)).toBe('string')
console.log(transform(code))

})`
3. The above test however fails on the commit where version 5.5.0 was released. I still can't figure out why

My current Hypotheses:

1. It could be a different version of svg-parser being used in the tests? (Unlikely)
2. Some minor difference in the code (Likely)

Right now, the issue is in one.js the type is undefined because svg parser takes the CDATA as literal Character Data and tries to keep it typeless

then in one.js SVGR tries to figure out what type it is, but there is no type, as mentioned the data is meant to be taken literally

Which results in the error being thrown

Possible fix:

1. Just hack one.js such that if type is undefined, we assume it is CDATA. This assumes that svg-parser throws an error when the type is undefined, which I think it does. Also introduces a whole bunch of edge cases

Hopefully the above helps anyone else who is investigating, if I manage to fix/hack it I'll post whatever I have here

[Rafael-Ramblas]

+1