Side-effect imports are checked if file uses JSX: unintentional breaking change?

[mattmccutchen]

Commit 7a71887 (#27340) appears to have introduced an unintentional breaking change: side-effect module imports are now checked, but only if the file uses JSX. This is currently causing the DefinitelyTyped CI (which uses typescript@next) to fail on @types/react-table.

TypeScript Version: 7a71887 (problem does not occur in 12e371b)

Search Terms: side effect module import jsx

Code

// code.tsx
import * as React from "react";
import "nope";
<div/>;
// tsconfig.json
{
 "compilerOptions": {
 "jsx": "react",
 "strict": true
 }
}
// package.json
{
 "devDependencies": {
 "@types/react": "^16.7.6"
 }
}

Expected behavior: No compile error.

Actual behavior: error TS2307: Cannot find module 'nope'. But if the JSX element is removed from the file, the error goes away.

Playground Link: N/A, React dependency

Related Issues: #28032, etc. for the previous behavior

[weswigham]

I called it out when it surfaced in our user suite this morning here. I wanted to double check that we didn't want to check them because TBH it's strange we don't - the only reason we didn't is because by chance we never attempted to resolve the export shape for the associated module and since, ofc, nobody asked for any (there aren't any requested, syntactically) the resolution never got checked.

[weswigham]

(Also it's not tied to jsx - anything that triggers a symbol visibility check on something in the containing file is the prerequisite - so declaration emit being on aughta do it, too)