Standard SVG transform pipeline doesn't understand Typescript

[samjt]

🐛 bug report

The standard SVG transform pipeline using @parcel/transformer-svg-react doesn't understand Typescript emitted by SVGR and assumes it is pure JS.

🎛 Configuration (.babelrc, package.json, cli command)

.parcelrc

{
    "extends": ["@parcel/config-default"],
    "resolvers": ["...", "@parcel/resolver-glob"],
    "transformers": {
        "*.svg": ["...", "@parcel/transformer-svg-react"]
    }
}

.svgrrc.yaml

# When generating icons from raw svgs, we need to expose the color value as a prop to make it modifiable in React
replaceAttrValues: { "#011e41": "{props.color}", "#adb9c3": "{props.color}" }
icon: true
dimensions: true
typescript: true

🤔 Expected Behavior

When typescript: true is set in the svgrrc.yaml, the pipeline should process the output of @parcel/transformer-svg-react as TypeScript and output typed definitions of svgs

😯 Current Behavior

The pipeline throws an error on encountering a :, presumably the type definition of the SVG.

🚨 Build failed.

@parcel/transformer-js: Expected ',', got ':'

💁 Possible Solution

Forcing Parcel to use a Typescript transform in the pipeline resolves the issue and generates proper types for the SVGs

{
    "extends": ["@parcel/config-default"],
    "resolvers": ["...", "@parcel/resolver-glob"],
    "transformers": {
        "*.svg": ["...", "@parcel/transformer-svg-react", "@parcel/transformer-typescript-tsc"]
    }
}

🔦 Context

Generate an Icon library from SVG files that works with a Typescript development environment.

💻 Code Sample

🌍 Your Environment

Software	Version(s)
Parcel	2.7.0
Node	16.13.1
npm/Yarn	3.2.2
Operating System	macOS 12.4

[mischnic]

I think the proper solution would be setting this to tsx instead if the typescript option is enabled, then it would use the pipeline that is used by all Typescript assets

parcel/packages/transformers/svg-react/src/SvgReactTransformer.js

Line 36 in 9e5d055

asset.type = 'jsx';

This PR will add proper config loading, so the config could be checked with that: #7741

[samjt]

Sure, that makes more sense, I guess I should describe the solution more as a workaround for the time being.