Type error when upgrading from 11.5 to 11.5.1 with skipLibCheck: false and using RN 0.70

[AugustinLF]

Describe the bug

While trying to upgrade to the RC (anyone could link me the thread where we were discussing the RC, I can't find it anymore), I realised I missed some minors updates, and found breaking types between 11.5.0 and 11.5.1.

node_modules/@testing-library/react-native/build/within.d.ts:48:152 - error TS2307: Cannot find module 'react-native/types' or its corresponding type declarations.

48     getAllByRole: import("./queries/makeQueries").GetAllByQuery<import("./matches").TextMatch, import("./queries/options").CommonQueryOptions & import("react-native/types").AccessibilityState & {
                                                                                                                                                          ~~~~~~~~~~~~~~~~~~~~

...

18  node_modules/@testing-library/react-native/build/render.d.ts:51
18  node_modules/@testing-library/react-native/build/within.d.ts:32

All errors are regarding the way the import of AccessibilityState is done as part of our build output.

Steps to Reproduce

Simply create a repo with RN@0.70 and a version of RNTL>=11.5.1, make sure to have skipLibCheck: false in the compilerOptions of your tsconfig and run typescript.

Versions

  npmPackages:
    @testing-library/react-native: 12.0.0-rc.0 => 12.0.0-rc.0
    react: 18.1.0 => 18.1.0
    react-native: 0.70.6 => 0.70.6
    react-test-renderer: 18.1.0 => 18.1.0

[mdjastrzebski]

@AugustinLF not sure I understand the issue here. What is the difference between the old way and the new way we import AccessibilityState?

[pierrezimmermannbam]

I have the same error. I think it's related to the update of react native on RNTL side and the fact that types are included in react native repo from version 0.71. It looks like it's looking for types within react native package but can't find them if they are in a separate package, which must be the case since @AugustinLF 's version of RN is 70.6. This commit happened during v11.5.0 and 11.5.1 2561380, I think it caused this issue.

[mdjastrzebski]

@pierrezimmermannbam @AugustinLF do you think this issue is resulting from our code or RN incorporating types itself? Our deps/peer deps are pretty slim and flexible:

[AugustinLF]

In RN 0.70, you get the types from @types/react-native, in RN 0.71 from RN itself, so the path to look for AccessibilityState. And since RNTL's build doesn't inline the AccessibilityState type, the output creates an incorrect link. Not sure I'm clear, if not, let me know, I'll try to make a diagram or something like that.

The solution IMO is to inline the type. Either it can be done through the compiler (i.e. keep writing import type { AccessibilityState } from 'react-native', but have the .d.ts outputed inline the type, or do the inlining by ourselves (i.e. redeclare AccessibilityState in our types).

[mdjastrzebski]

And since RNTL's build doesn't inline the AccessibilityState type, the output creates an incorrect link. Not sure I'm clear, if not, let me know, I'll try to make a diagram or something like that.

I am confused here, could you do this diagram. My understanding is that our types exports are passthrough to RN types whether they are defined in react-native or @types/react-native. We even import them in the same way:

import type { AccessibilityState } from 'react-native'

So it would make sense for the types to reflect the types from user's React Native version rather than whatever concrete version for RN types we choose.

[mdjastrzebski]

It seems that our import type { AccessibilityState } from 'react-native' gets transpilled by TSC/Babel into two slightly different outputs:

Before (11.5.0) - within.d.ts:

getAllByRole: import("./queries/makeQueries").GetAllByQuery<import("./matches").TextMatch, import("./queries/options").CommonQueryOptions & import("react-native").AccessibilityState & {

After (11.5.1) - within.d.ts:

getAllByRole: import("./queries/makeQueries").GetAllByQuery<import("./matches").TextMatch, import("./queries/options").CommonQueryOptions & import("react-native/types").AccessibilityState & {

So for external @types/react-native this was import("react-native"), while for internal react-native types it is import("react-native/types". Now, that seems to be quite complex to solve.

[mdjastrzebski]

I've done using our basic examples app, which uses Expo 47 / React Native 0.70.5. When I upgrade RNTL to 11.5.2 it runs tests fine, with and without @types/react-native package.

@AugustinLF is this error occurring for you under regular Jest or TS Jest?

[AugustinLF]

It seems that our import type { AccessibilityState } from 'react-native' gets transpilled by TSC/Babel into two slightly different outputs:

Yep that's exactly the problem/difference.

it runs tests fine

I've reproduced the error by simply running tsc, not typescript, but you need to explicitly enable skipLibCheck: true, because our config extends expo's one that by default disables that options.

[pierrezimmermannbam]

Even without enabling skipLibCheck the resolved type of getByRole options is any since it uses AccessibilityState

[mdjastrzebski]

@AugustinLF @pierrezimmermannbam do you have any suggestion how we could solve it?

E.g. would importing @types/react-native in dev deps during the TS d.ts file generation process solve the issue?

[mdjastrzebski]

I've did a simple experiment on basic example by reverting RNTL to 11.5.0 (which used the @types/react-native package):

"devDependencies": {
  "@babel/core": "^7.19.3",
  "@testing-library/jest-native": "^5.4.0",
  "@testing-library/react-native": "11.5.0",
  "@types/react": "~18.0.24",
  "@types/react-native": "~0.70.6",
  "jest": "^29.3.0",
  "react-test-renderer": "18.1.0",
  "typescript": "^4.8.4"
},

Then I've run yarn typecheck but got a lot of other type errors:

Errors  Files
     1  node_modules/@testing-library/jest-native/extend-expect.d.ts:3
     1  node_modules/@types/node/globals.d.ts:72
    43  node_modules/@types/react-native/globals.d.ts:58
    12  node_modules/typescript/lib/lib.dom.d.ts:2042

I wonder how practical skipLibCheck: false approach is when default Expo project throws a lot of errors with it.

[AugustinLF]

Even without enabling skipLibCheck the resolved type of getByRole options is any since it uses AccessibilityState

I wonder how practical skipLibCheck: false approach is when default Expo project throws a lot of errors with it.

Yep, that's part of the reasons why we recently flipped the config to true. It can be messy to enable and we had to patch some of the RN provided types to avoid conflicts, but without that, we end up with a lot of silent anys and other unsafe uses of our APIs.

I've did a simple experiment on basic example by reverting RNTL to 11.5.0 (which used the @types/react-native package):

It's indeed not ideal, but in our case we managed to fix all our other errors. Bumping RNTL to 11.5.1 does bring those additional error.

E.g. would importing @types/react-native in dev deps during the TS d.ts file generation process solve the issue?

I don't know, I'm not sure how the output is created, and I don't know if ts would still go for the @types/react-native given the fact that react-native exposes types itself. And we need to make it work for both 0.70 and 0.71. I'll see if I can try that.

And if that doesn't work, we can redeclare the types ourselves.

[pierrezimmermannbam]

I don't think importing @types/react-native could fix the issue, if the type is then imported from this package it would not work for users who have a version of React Native >= 0.71 unless they keep this package which is not ideal. One solution would be to have versions that support only React Native >= 0.71 and others for older versions but it would be hard to maintain. Another solution is to declare those types in RNTL repo. It's also not ideal but if those types rarely change then we could have a broader range of React Native versions as peer dependencies.

It's also not a very important issue so both these solutions seem overkill. Surely someone else must have experienced this issue, I'll ask on the React Native repo what is the recommended approach