To ensure compatibility with various React libraries, it is important to update the version of the @types/react package. Many libraries have set their dependency to @types/react : "*", which automatically fetches the latest version (currently assumed to be 18).

You can specify the desired version in your package.json file by adding the following:

"resolutions": {
  "@types/react": "^17.0.38"
}

If you are using npm instead of yarn, make sure to include the following in the "scripts" section of your package.json:

"preinstall": "npm install --package-lock-only --ignore-scripts && npx npm-force-resolutions"

This command utilizes the npm-force-resolutions package to manage version conflicts.

After running npm install, your application should function properly without any issues.

Encountered a similar issue while using Styled Components. When resolutions weren't effective, I found an alternative solution:

Implementing brute force type casting:

const CustomThemeProvider = ThemeProvider as unknown as React.FC<PropsWithChildren<{ theme: string }>>;

Today, I encountered an issue.

rm -rf node_modules
rm -rf yarn.lock
npm install

I managed to solve the problem by simply using npm install, but I am unsure of what actually happened.

I encountered a similar issue while working on a Yarn monorepo that included a Typescript create-react-app subproject with the configuration

installConfig.hoistingLimits=workspace

. This setup prevented dependencies from being hoisted to the top-level of the monorepo.

During the execution of react-scripts start, the type checker was referencing the top-level @types directory instead of locating the appropriate @types/react for the specified React version in the project. To resolve this issue, I added the following snippet to the tsconfig.json within the subproject:

"compilerOptions": {
  ...
  "typeRoots": ["./node_modules/@types"]
},
...

By including this configuration, Typescript was able to access the relevant type definitions specific to the sub-project.

Sahil's response is accurate for npm and yarn, but if you opt for pnpm, a slightly different configuration is required in your package.json file:

"pnpm": {
  "overrides": {
    "@types/react": "^17.0.38"
  }
}

If you are managing a monorepo with multiple packages, remember that this setting applies only to the primary package.json file at the root of your project. For more detailed information, refer to the documentation on pnpm overrides.

Encountering a similar problem, I decided to upgrade my npm version from ^6.0.0 -> 8.0.0 which successfully resolved the issue at hand.

Make sure to verify your current npm version as well.

During my recent upgrade to React 18, I encountered an issue that arose from forgetting to update the corresponding types in devDependencies.

To resolve this issue, I simply updated the React types in the package.json file to ensure they matched correctly:

{
    ...
    "dependencies": {
        ...
        "react": "^18.1.0",
    },
    "devDependencies": {
        ...
        "@types/react": "^18.0.8",
    }
}

After encountering a challenging issue, I managed to find a solution. However, it's important to note that there was no easy fix for this problem.

To resolve the issue, I took a proactive approach by uninstalling all @types packages that I suspected were causing the errors. Identifying these problematic packages simply involved reviewing the error messages displayed in my window. The key hint came from the specific error message highlighted above.

The error indicated: "Type 'React.ReactNode' is not assignable to type 'import(/home/user/app/node_modules/@types/react-bootstrap-table-next/node_modules/@types/react/index).ReactNode'."

If you notice that the node module types are pointing to a different package unrelated to your library, it's best to remove it. In my case, the culprit was the TimeAgo package, which was causing type conflicts with another package. By systematically removing and rechecking the errors, I was able to pinpoint and eliminate the root cause of the issue.

Subsequently, I utilized npm run build to conduct type checks and identify the necessary types that needed reinstatement. While this process was somewhat tedious, it effectively resolved the problem in my case.

This type of issue often arises when multiple libraries share similar dependencies. Over time, unused or redundant types can accumulate in your package.json file if they are not properly managed.

If you suspect that certain types may be conflicting with your library, consider uninstalling them temporarily to see if the error disappears. Reinstall any essential types as needed, especially if additional errors indicate missing dev type packages. It's also worth noting that some @type packages might function better as devDependencies rather than regular dependencies.

When unsure about which types are causing conflicts, a systematic approach of removal and reinstallation is recommended to troubleshoot and ultimately resolve the issue.

If your npm version is outdated, simply upgrade it to a version greater than 8.0.0. This solution worked like a charm for me.

Having an older npm version (6.x.x), I experimented with various fixes, only to find that updating npm to the latest version quickly resolved the issue.

Don't forget to check your npm version!

Make sure to verify the versions of node and npm that are currently installed on your system. If you decide to upgrade to version 8.x, npm will offer a similar feature as resolution in yarn, known as "overrides." To update your package, use the following code:

"overrides": {
  "@types/react": "17.x.x",
  "@types/react-dom": "17.x.x"
}

While my local instance had the latest npm and node versions, this was not the case for the git ci environment. However, after performing the necessary updates, the project ran smoothly without requiring any overrides for react and react-dom versions.

Unfortunately, I am unable to use the top-voted solution in my situation as I require @types18 for utilizing the latest hooks from react@18 such as useId. Using @types/react@17 is not feasible as it does not provide exported members for these hooks.

Thanks to the response from @Chris Web, I managed to make use of the latest types by resolving the issues with typed dependencies. For instance, for the Redux Provider:

// temporary workaround for @types/react@18
const Provider = _Provider as unknown as React.FC<{
  children?: JSX.Element | string;
  store: any;
}>;

Although using store: any is not ideal, it serves as a temporary fix for now.

To fix this issue, simply implement the solution provided above for react.

"resolutions": { "@types/react": "17.0.2", "@types/react-dom": "17.0.2" },

For react-native, there is no need to include types for react-dom:

"resolutions": {
"@types/react": "17.0.2",

}, If you continue to encounter errors with react types, install the type package separately for react:

npm install -D @types/<a href="/cdn-cgi/l/email-protection" class="__cf_email__" data-cfemail="abcdefabc9c8caece5fbf5ebeb84efe9">[email protected]</a>

Remember - do not use "^" in the resolution as it will attempt to install the latest package versions, potentially causing the same issue.

Issue

If you encounter a specific error in the application while utilizing yarn rather than npm.

Fix

To resolve this, include the necessary changes to the resolutions and preinstall script within the package.json file and then run yarn preinstall followed by yarn.

• package.json

"resolutions": {
    .....
    "@types/react": "^17.0.38"
    ....
  },


"scripts": {
    ......
    "preinstall": "yarn --package-lock-only --ignore-scripts"
    ......
  },

Additional Information

• Source

Here's a slightly altered solution that helped me resolve the issue (just in case the previous one doesn't do the trick for you). I discovered that there was a node_modules folder located in my user root directory. This is how my project folder structure appeared:

~/checkouts/project/node_modules

In addition, there was an extra node_modules folder mistakenly installed in the user root directory:

~/node_modules

Keep in mind that npm packages operate by scanning through the directory structure and collecting npm packages as it goes. Once I removed this unnecessary directory, the problem was resolved.

After conducting tests on two Windows machines, one Mac, and one Ubuntu, it was discovered that one of the Windows machines had no build errors, while the other Windows machine and Ubuntu both experienced errors during the build process. Despite testing with different node versions, the issue persisted. Ultimately, updating some types versions resolved the error:

"@types/react": "^18.0.15",
"@types/react-dom": "^18.0.6",
"@types/react-router": "^5.1.18",
"@types/react-router-dom": "^5.3.3",

After experimenting with different methods, I first used yarn's resolution to resolve the issue. However, when I deleted my yarn.lock file and updated the type for React, that also resolved the issue without relying on yarn's resolution.

yarn upgrade @types/react@^18.0.21