TSConfig' JSX option should not list react as an unlisted dependency

[AndreaPontrandolfo]

Hello, thank you for this amazing tool!

I use a TSConfig for a typescript project and i specify the jsx option.
I don't have React as a dependency in the project because it's not needed.
Yet Knip complains that it's an "unlisted dependency".
I don't understand why is that.
I have no evidence that if you set the jsx option you are required to use React.
As a matter of fact, in my project nothing unexpected happens.
What tsc does is: if it encounters some React code during compilation, it look for that instruction and act accordingly. If the jsx instruction is not set by the user, tsc will compile jsx with the default settings.
If there is no react/jsx code in the project, but the jsx setting is set, nothing unexpected happens.

So i think this is a uninted behaviour by Knip.

Note: i don't think this is related to #186

[webpro]

Yes, agreed. There are 6 values (excluding undefined here) and 2 of them are "none" and "preserve" in which case react should not be an expected dependency indeed (the other 4 all do). Am I right in assuming you're using "none" or "preserve"?

[AndreaPontrandolfo]

Am I right in assuming you're using "none" or "preserve"?

No, i'm using react-jsx.

(the other 4 all do)

Can you clarify why react is an expected dependency if i set the jsx option? Expected by who? tsc doesn't complain or output any type of warning. Also no mention of it in the typescript docs.

Full context: i have a monorepo, where most of the packages are in Typescript. Some of the packages use React, some don't. To avoid complexity and duplication, i have a single base tsconfig where i set every needed value and every package of the monorepo extends from that base tsconfig. I set the jsx option in the base config, which is why all the packages inherit it. It does no harm and is completely unconsequential, yet knip complains.

[webpro]

Am I right in assuming you're using "none" or "preserve"?

No, i'm using react-jsx.

(the other 4 all do)

Can you clarify why react is an expected dependency if i set the jsx option? Expected by who? tsc doesn't complain or output any type of warning. Also no mention of it in the typescript docs.

TypeScript compiles JSX to React.createElement calls and/or pragmas (i.e. comments at the of files like /** @jsxImportSource preact */), this eventually requires react (or whatever handles the result of the compilation).

https://www.typescriptlang.org/tsconfig#jsx and https://www.typescriptlang.org/docs/handbook/jsx.html

In theory it's possible that nothing in the source code imports react directly, but react is still a required dependency because of the above. Yet this also depends on the bundler and whatnot. The error message "React is undefined" was/is a common issue (at least in part) because of this.

In practice I guess there's almost always something explicitly importing something from react. But maybe less so when the jsxImportSource is an alternative renderer (e.g. hastscript/svg in which case hastscript is the returned dependency).

So, here were we are. Balancing act, if you ask me. I'll dig into it some more and see if there's a way out for better handling of more use cases. And yes, maybe it'll end up in simply removing the react dependency from Knip's TypeScript plugin.

Full context: i have a monorepo, where most of the packages are in Typescript. Some of the packages use React, some don't. To avoid complexity and duplication, i have a single base tsconfig where i set every needed value and every package of the monorepo extends from that base tsconfig. I set the jsx option in the base config, which is why all the packages inherit it. It does no harm and is completely unconsequential, yet knip complains.

Knip complains a lot (aka false positives). It's still early days and figuring things out, as the JS/TS ecosystem is vast and honestly it's mostly heuristics based on things that sometimes work together in surprising ways.

[webpro]

Eventually this behavior has been fixed. I think the pros outweigh the cons by not trying to be smart here. Thanks for raising this, @AndreaPontrandolfo :)

[AndreaPontrandolfo]

@webpro Thank you for fixing it!