ts-migrate is inserting comments in JSX components

I’m giving ts-migrate a try to migrate a large gatsby project. My issue is JS comments are inserted in components:

export function Input(props: any) {
  return props.readonly ? (
    <div className={style.readonlyInputField} style={props.style}>
      {props.value}
    </div>
  ) : (
    <div className={style.inputField} style={props.style}>
      // @ts-expect-error ts-migrate(2607) FIXME: JSX element class does not support attributes beca... Remove this comment to see the full error message
      <RawInput className={style.input} {...props} />
    </div>
  )
}

This makes them visible in the rendered output. They should be inserted with braces instead:

export function Input(props: any) {
  return props.readonly ? (
    <div className={style.readonlyInputField} style={props.style}>
      {props.value}
    </div>
  ) : (
    <div className={style.inputField} style={props.style}>
      {/* @ts-expect-error ts-migrate(2607) FIXME: JSX element class does not support attributes beca... Remove this comment to see the full error message */}
      <RawInput className={style.input} {...props} />
    </div>
  )
}

I ran npx -p ts-migrate -c "ts-migrate-full ." at the root of the project. During the migration I saw a lot of occurrences of this error:

Error: [react-props][src/components/multiStates.tsx] Error:
 TypeError: Cannot read property 'length' of undefined
    at isReactSfcFunctionDeclaration (/home/flupke/src/jitter/jitter.video/frontend/node_modules/ts-migrate-plugins/build/src/plugins/utils/react.js:32:40)
    at Array.filter (<anonymous>)
    at Object.getNumComponentsInSourceFile (/home/flupke/src/jitter/jitter.video/frontend/node_modules/ts-migrate-plugins/build/src/plugins/utils/react.js:76:10)
    at Object.createPropsTypeNameGetter (/home/flupke/src/jitter/jitter.video/frontend/node_modules/ts-migrate-plugins/build/src/plugins/utils/react-props.js:239:41)
    at Object.run (/home/flupke/src/jitter/jitter.video/frontend/node_modules/ts-migrate-plugins/build/src/plugins/react-props.js:42:48)
    at Object.migrate (/home/flupke/src/jitter/jitter.video/frontend/node_modules/ts-migrate-server/build/src/migrate/index.js:65:46)
    at async Object.handler (/home/flupke/src/jitter/jitter.video/frontend/node_modules/ts-migrate/build/cli.js:130:22)

I have 108 .tsx files in the project so this will be cumbersome to fix, did I do something wrong during the conversion?

[lnrdgmz]

I’m experiencing the same problem. I tried to pinpoint the problem by stepping through with the debugger, but I was unable to find the point of failure.

I changed versions of TypeScript to see if that could be the issue, and found the issue does not exist when using v4.2.4. With this version, I get the expected output after running yarn ts-migrate migrate:

export default ({
  name
}: any) => {
  return (
    // @ts-expect-error ts-migrate(7026) FIXME: JSX element implicitly has type 'any' because no i... Remove this comment to see the full error message
    <div>
      {/* @ts-expect-error ts-migrate(7026) FIXME: JSX element implicitly has type 'any' because no i... Remove this comment to see the full error message */}
      <div>Hello, {name}!</div>
    {/* @ts-expect-error ts-migrate(7026) FIXME: JSX element implicitly has type 'any' because no i... Remove this comment to see the full error message */}
    </div>
  )
}

With versions 4.3.2 and 4.4.4, I get the following:

export default ({
  name
}: any) => {
  return (
    // @ts-expect-error ts-migrate(7026) FIXME: JSX element implicitly has type 'any' because no i... Remove this comment to see the full error message
    <div>
      // @ts-expect-error ts-migrate(7026) FIXME: JSX element implicitly has type 'any' because no i... Remove this comment to see the full error message
      <div>Hello, {name}!</div>
    // @ts-expect-error ts-migrate(7026) FIXME: JSX element implicitly has type 'any' because no i... Remove this comment to see the full error message
    </div>
  )
}

[sharmilajesupaul]

@Rudeg @brieb @lencioni +1 i’m also able to repro this bug in typescript@4.4.4 A meta question: can we add a help-wanted label? so that the community can pick those up and contribute these fixes?