[update-react-imports] skips files that contain type imports

[TkDodo]

current behaviour

files that include React runtime code, like React.useState, are properly handled by the code-mod. However, as soon as there is a single type import from React, like React.ReactNode, it shows the complete file as SKIP. Example file that will be skipped:

import * as React from 'react'

export const Counter = () => {
    const [count, setCount] = React.useState(0)

    const increment = (event: React.MouseEvent<HTMLButtonElement>) => {
        console.log(event)
        setCount(count + 1)
    }

    return (
        <button type="button" onClick={increment}>
            inc
        </button>
    )
}

As soon as we change to e.g. event:any, the file is correctly processed.

The following settings were used:

? On which files or directory should the codemods be applied? .
? Which dialect of JavaScript do you use? TypeScript
? Destructure namespace imports (import *) too? Yes

expected behaviour

type imports are transformed exactly like runtime imports, so the above example should become:

- import * as React from 'react'
+ import { useState, MouseEvent } from 'react'

export const Counter = () => {
-    const [count, setCount] = React.useState(0)
+    const [count, setCount] = useState(0)

-    const increment = (event: React.MouseEvent<HTMLButtonElement>) => {
+    const increment = (event: MouseEvent<HTMLButtonElement>) => {
        console.log(event)
        setCount(count + 1)
    }

    return (
        <button type="button" onClick={increment}>
            inc
        </button>
    )
}

[TkDodo]

related:

• https://github.com/reactjs/react-codemod/issues/283

potentially fixed by:

• https://github.com/reactjs/react-codemod/pull/305

[amirabbas-gh]

Thanks for the pointers, Dominik! @TkDodo I took that into account, added support for more edge cases, and checked in the codemod here. Alex also published it to the registry, so devs can now just run npx codemod@latest react/update-react-imports. I'm having permissions issues opening a PR against this repo, but Alex and @rickhanlonii are looking into it.