Break with typescript's generic component about jsxstyle

[meyer]

@Sunshine168 ooh, I’ll take a look now. I have a few initial questions for you:

• Can you provide me with more information about your environment? Version numbers of jsxstyle and TypeScript would be super helpful.
• Are you using jsxstyle on its own, or are you using jsxstyle with jsxstyle-webpack-plugin?
• Did you just add jsxstyle to this project, or have you been using jsxstyle with this project for a while?

Thanks!

[Sunshine168]

@meyer Hello
Version:

"jsxstyle": "^2.1.3,
"jsxstyle-webpack-plugin": "^1.1.3",
"typescript": "^3.0.1",

We use jsxstyle with jsxstyle-webpack-plugin and using jsxstyle with this project for a long time

[meyer]

Thanks for the info, @Sunshine168. Reproducing this bug was quite easy—looks like an issue on the babel side of things. I’m looking at switching the parser to use typescript-estree instead of @babel/parser, which would give us support for any new TypeScript features that might come along (including JSX type parameters). I’ll keep you updated here as I make progress on the switch.

[meyer]

@Sunshine168 I haven’t had a lot of time to work on switching the parser to typescript-estree. I did realise yesterday that this issue has already come up and has a solution:

It’s not ideal, but basically babel-loader needs to run in addition to ts-loader. Here’s how things need to be configured:

• JsxstyleWebpackPlugin.loader should run after ts-loader (see example)
• compilerOptions.jsx should be set to "preserve" in your tsconfig (see example)
• babel-loader should run after JsxstyleWebpackPlugin.loader to transpile JSX (see example)

Since jsxstyle-webpack-plugin is already parsing JSX, I can look into adding a transpileJsx option so that the babel-loader portion can be skipped.

Let me know if that works for you, or if you have a better solution.