Definitelytyped: node_modules/@types/react-native/globals.d.ts (36,15): Duplicate identifier 'FormData'.

Same here

Why @types/react-native was added at all? I have a react web project, why do I have to install typings I don't use?

Fixed by set compilerOptions.types manually

{
  "compilerOptions": {
  ...
    "types": ["react", "jest"]
  }
  ...
}

I have the same issue too.

Same issue here.
Since I have multiple type definitions in my project I set fixed the @types/styled-components dependency to a previous version.

I think adding types explicitly to tsconfig.json is a poor solution.
It would be better to separate the types for styled-components for web and for native.

I'm having an issue with this FormData, I'm using typescript: 3.3.333 here is my package.json and tsconfig.json

PACKAGE JSON
"dependencies": { "@material-ui/core": "^3.9.2", "@types/react-loadable": "^5.5.0", "@types/react-router-dom": "^4.3.1", "prettier": "^1.16.4", "react": "^16.8.4", "react-dom": "^16.8.4", "react-loadable": "^5.5.0", "react-router-dom": "^5.0.0", "react-scripts-ts": "3.1.0", "styled-components": "^4.1.3" }, "devDependencies": { "@types/jest": "^24.0.11", "@types/node": "^11.11.3", "@types/react": "^16.8.8", "@types/react-dom": "^16.8.2", "@types/styled-components": "^4.1.12", "eslint": "5.3.0", "eslint-config-airbnb-base": "13.1.0", "eslint-plugin-import": "^2.14.0", "typescript": "^3.3.3333" }

TSCONFIG JSON
{ "compilerOptions": { "baseUrl": ".", "outDir": "build/dist", "module": "esnext", "target": "es5", "lib": ["es6", "dom"], "sourceMap": true, "allowJs": true, "jsx": "react", "moduleResolution": "node", "rootDir": "src", "forceConsistentCasingInFileNames": true, "noImplicitReturns": true, "noImplicitThis": true, "noImplicitAny": true, "importHelpers": true, "strictNullChecks": true, "suppressImplicitAnyIndexErrors": true, "noUnusedLocals": true, "esModuleInterop": true, "types": ["styled-components", "react", "react-dom", "jest"] }, "exclude": [ "node_modules", "build", "scripts", "acceptance-tests", "webpack", "jest", "src/setupTests.ts" ] }

I have the same problem. Luckily, I was able to overcome the issue by locking the version of @types/styled-components to 4.1.8

Same here, I had to either roll back to a previous version, or add a postinstall script to remove react-native from node_modules

How are you even supposed to use styled-components on the web at all if it's dependencies clash by default with the dom libs?!
This is insane!

I have the same issue and I also noticed that not all the authors were notified. These two are missing: @eps1lon @flavordaaave

@ArthurBrito thanks, list of authors was updated.

This issue is happening for me as well. @types/react-native should not be a dependency in web projects. These types should be separated

As far as I can tell this was caused by #32843 which was released as 4.1.9. This comment backs that up.

I posted a comment in that thread referencing to this issue.

/cc @minestarks

fixing verison to 4.1.8 worked for me

Is there a PR here that addresses this problem? Strange you cannot use styled-components in web projects.

Got the same problem, indeed it's about @types/styled-component.

my-app git:(master) ✗ npm ls @types/react-native
[email protected] /Users/devniel/dev/electron/my-app
└─┬ @types/[email protected]
  └── @types/[email protected]

Any update to the issue?

Create a .yarnclean file with the following content:

@types/react-native

fixes the issue 🎉

Half a year and still no updates for this issue?

Really no update???

I my opinion, the best solution would be to make @types/react-native a peer dependency, but to my knowledge types-publisher isn't supporting these at the moment. Can one of the maintainers please verify that I'm in fact right and peerDep is a solution? I may be able to spend some time on the weekend adding peerDep support to types-publisher, if we're good to go.

I my opinion, the best solution would be to make @types/react-native a peer dependency

Hmm, if @types/react-native is a peer dep, I'd need to declare it as a dependency in order to use @types/styled-components in a non-React Native project. That isn't ideal.

Ideally @types/react-native would not be required by a non-React Native project; and I especially shouldn't have to _declare_ it as a dependency.

Do you mean to make it an optionalDependency?

@paulmelnikow, yes, you're right, I've confused the two. You still wouldn't need to declare @types/react-native as a dependency in order to use @types/styled-components, but you'll get a pesky warning, so optionalDeps is a better solution, of course. types-publisher does not support them as well, and I'll try to look into it

Downgrading to "@types/styled-components": "4.0.0" solved the problem.

No, it not solves. It sweeps problem under the carpet

No, it not solves. It sweeps problem under the carpet

Let's say it compile again? ;-)

Create a .yarnclean file with the following content:

@types/react-native

fixes the issue 🎉

Does there is any equivalent with npm ?

any progress on this issue?
it makes styled-components unusable with typescript.

Diving into the actual code of this repo, you can clearly see that @types/react-native is ONLY needed in the actual .d.ts and test file for the React Native integration. I think a more appropriate solution would be for anything related to React Native to be split out into it's own submodule/optional/peer dependency, consistent with the behaviour of how styled-components actually works, you import styled-components/native if you want the React Native stuff. You don't import styled-components and get the entire jungle of React Native stuff too in runtime, so by importing just styled-components I shouldn't be also getting the entire jungle of @types/react-native types.

I think for the meantime the react-native integration should be deleted from the NPM published version of this package, and published as it's own package. As it stands this is embarrassingly broken and makes TypeScript as a whole look bad

Please please fix this issue. Take the native types out ASAP. This makes what is an otherwise excellent typing project nearly unusable.

Diving into the actual code of this repo, you can clearly see that @types/react-native is ONLY needed in the actual .d.ts and test file for the React Native integration. I think a more appropriate solution would be for anything related to React Native to be split out into it's own submodule/optional/peer dependency, consistent with the behaviour of how styled-components actually works, you import styled-components/native if you want the React Native stuff. You don't import styled-components and get the entire jungle of React Native stuff too in runtime, so by importing just styled-components I shouldn't be also getting the entire jungle of @types/react-native types.

👍

I think for the meantime the react-native integration should be deleted from the NPM published version of this package, and published as it's own package.

I think that could be a solution, though also wonder if there might be a way to ship them both in the same package, as was the thrust of #32843, without causing this problem.

Just a friendly note to say that the best way to get this fixed is to dig in and open a PR with a solution, or to find someone specifically invested in Styled Components who can fix.

DefinitelyTyped provides an awesome service to the package community and there are maintainers here, though their job isn't to maintain all the types. Shaking your fist at this project (or at TypeScript) is not going to help.

I'm switching to emotion
They include their own typescript definitions, and have the exact same interface so migrating is an easy find and replace all.
Plus the bundle size is a little smaller.

How about we just revert the changes introduced in #32843, since it broke the typings for like >90% of users and forced them to use outdated version or some hacks mentioned in this thread.

How about we just revert the changes introduced in #32843, since it broke the typings for like >90% of users and forced them to use outdated version or some hacks mentioned in this thread.

That could be a reasonable solution if it makes the typings work better for the vast majority of users. I don't know for sure if the PR would get approved or not, but if you feel it's the best solution, do feel free to make a PR.

I think if this revert were to be done, it would be to add some notes to the package on how to get it to work with react-native afterwards. I haven't tried it out, but it'd probably be possible for react-native users to copy and paste the removed typings in to their project with a declare module declaration and have things continue to work. Though obviously it's a shame to have to make react-native users do this.

Though tbh, I'd love if the TypeScript team could provide any official guidance on how to handle issues like these, since it seems like someone ends up "losing" in all solutions.

IMO, this should be reverted - mainly because the web styled components eco-system is bigger.

I don't know all the details fo how it works anymore, but it used to be that for React Native you would get a different set of types by using a different path which seemed like a good compromise to me. Hrm, looks like this is what brings. that back into it.

I wonder if maybe there could be a way to have an ambient module that people import via a triple slash import which adds the react-native specific types?

+1 here, but not only complaining, if there's a plan of action I want to participate and help solve this issue.

I came here, went to add my plus one to some of the comments. Realised I had already done so... the last time I encountered this issue.

And that is why I've begged other library maintainers to keep hold of their types. It forces the library to update inline with their types. I love that def typed has helped the community in many ways, but when the lib maintainers have the ability to type it themselves (or even rewrite in ts) it makes for a safer world.

I was also staying chill and calm about this issue as I was able to workaround this issue via a local clone but I think people around the world had suffered enough from this issue (more than 6 months). I want this critical and crippling issue fixed, and allow non-tech savvy typescript users to jump back in.

Is there any PRs that are awaiting approval? Should I put a single line of code change that removes invalid react-native global dependency(As I did inside my private npm repo)?

Also, is there a reason that react-native should be installed and conflict with global namespaces? Please chime in and share your thoughts. (But I wonder if those people who unintentionally broke our work would ever read this issue, as they would be as happy as they should be having no clue about our damage. I can't say I was never at the other end of such case before.)

Moreover, how do other packages deal with this kind of issue? I have no clue about it so kinda hesitant to make a _"simple"_ PR that reverts this problem.

While I think this change should be reverted, we had no need to enable skipLibCheck to make this work: https://github.com/DefinitelyTyped/DefinitelyTyped/issues/33311#issuecomment-466731156 . Please don't.

I don't think that reverting this change is a good option. A lot of people need typings for react-native and we should fix the thing that causes an error and not remove all react-native typings.

And if there is no solution at the moment? We should at least provide one release for non-native users as it's utterly broken at the moment and has been for a while, and I'd venture to guess that non-native users are also the majority.

any updates on this?

@dawick people who need typing for react-native can install them manually.
Why do they needed at all?

I don't think that reverting this change is a good option. A lot of people need typings for react-native and we should fix the thing that causes an error and not remove all react-native typings.

People who need typings for react-native should obtain them by installing @types/react-native.

I'm still strongly of the position that everything related to react-native should be deleted from @types/styled-components and moved to a different package/path e.g. @types/styled-components/native to be consistent with how people actually use styled-components; people who want react-native support explicitly get it by using import styled from 'styled-components/native', you don't get the entirety of all the react-native jungle by doing import styled from 'styled-components' in a web project, so the associated @types/ packages shouldn't behave any differently

I took a stab at fixing this in a more systemic way over the weekend, which could work for any repo that wraps types for both web + react native. https://github.com/microsoft/types-publisher/pull/655

how has this not been addressed...

Seriously? Still no fix?

@givethemheller @sanex3339 there is a fix in the works and discussion at https://github.com/microsoft/types-publisher/pull/655

As a temporary solution, just remove @types/react-native from node_modules:
rm -rf node_modules/@types/react-native
and add it to.yarnclean
@types/react-native

With the release of TypeScript 3.7, we now find ourselves in a situation where 3.7 users are _forced_ to upgrade their type definitions, as the previously working v4.1.8 is now incompatible with TS 3.7, but the only version compatible with TS 3.7 is utterly broken for every React-web developer (which surely must be the vast, overwhelming majority). 😕

The .yarnclean workaround probably suffices for those who use Yarn, which includes less than everyone. And modifying compilerOptions is not at all a scalable, long-term solution.

I don't know what the best solution here is. As a stopgap I'm definitely in favour of publishing a separate version that specifically excludes the react-native things.

As a non-yarn user you can work-around it by adding this to your npm scripts:

    "postinstall": "rm -rf node_modules/@types/react-native"

Will cause NPM to delete the native types immediately after it installs them. Still a hacky workaround for what shouldn't even be an issue but it works.

Adding myself here as well. We need a solution, better than editing a lot of postinstall scripts...

This issue is impacting basically all typescript users of styled-components for more than a year (!!!).
Do we have any official solution for this (not counting the hacks with .yarnclean)? Are there any blockers?

I feel like dividing this into two packages (or potentially three, a base one with common stuff for both react-native and react, one for react and another for RN, and make the two latter use the first one with the common stuff) would be the easiest and the fastest way to deal with that.

I'm more than willing to help, if we are only lacking contributors, I just want it to be easier to use both styled-components and typescript together, without having to hack stuff around 😄

I just want it to be easier to use both styled-components and typescript together, without having to hack stuff around 😄

Bump! There must be a better type definition implementation...

I removed @types/react-native from my node_modules and still getting the same error. Why even with the hack ?

@ArnaudJeannin if you manually deleted it by hand it will be getting added back every time you run npm i / yarn

To make the deletion persistent through installs either removing it via NPM postinstall as per my previous comment or adding it to .yarnclean if you use Yarn should work fine.

What I did won't be appropriate for everyone, but I "solved" this problem by switching from styled-components to emotion. My usage of either library is pretty basic-- just wrapping components with CSS and inheriting styles-- but I found Emotion to have a similar API to styled-components for the features i needed. It was an easy transition. I haven't run into any significant issues so far after 6 months. Emotion includes built-in TS typings so there's no out-of-sync issues with @types.

As noted above, switching CSS libraries won't be appropriate for many projects, but for me switching was easier than wrangling with styled-components TS issues. YMMV.

Simpler workaround for yarn users, that will let you use current version of styled-components. In package.json:

  "resolutions": {
    "@types/react-native": "link:./empty-package"
  },

Set up a do-nothing package that's the target of the resolution above:

mkdir empty-package
cd empty-pacakge
yarn init -y
touch index.d.ts

Works for me.

@arimah @GabrielDuarteM, can you explain your downvote? Did you try this, and find it didn't work? Please comment so I can help and so others might benefit if so. This seems a lot less invasive than the only other workaround available at this point (a postinstall script to delete the type module). Or if there's some strong negative to this workaround that I haven't realized, I'd like to revise or remove the comment.

@jamietre I believe the downvotes are that while this might work, this is not the correct solution and doesn't change the fact that the types need to be split (or perhaps peer dependencies) for react-native

@jamietre I believe the downvotes are that while this might work, this is not the correct solution and doesn't change the fact that the types need to be split (or perhaps peer dependencies) for react-native

Didn't realize that workarounds were frowned upon. I always find them very helpful while waiting for a real fix. This has been an issue for over a year. and work still needs to get done. 🤷‍♂

@jamietre I think it's just that you framed it as a "solution", which it's not, and framing it as such might give the maintainers the idea that this isn't still a ridiculous issue affecting the majority of their users.

@jamietre I think it's just that you framed it as a "solution", which it's not, and framing it as such might give the maintainers the idea that this isn't still a ridiculous issue affecting the majority of their users.

Changed "solution" to "workaround"... really I'm just trying to help people be able to use styledcomponents with typescript. The downvotes imply it doesn't work. Doesn't seem helpful to quibble about semantics but sure.

In Appsome Solutions we had the same problem and we workarounded it with "skipLibCheck": true, rule in a tsconfig.json file.

@pumanitro Like many other things suggested, that's unfortunately not a solution but a mere workaround.

@SamHH Changed word solved to workarounded.
This is how it is done in CRA with typescript, but you are right it is not a solution. Still, it can help people.

Reposting my comment from https://github.com/DefinitelyTyped/DefinitelyTyped/pull/32843#issuecomment-605921101

The workaround is to have a compilerOptions.types array in your tsconfig.json that stops typescript from automatically reading every single @types/* package when typechecking. Typescript will only automatically import the types of packages named in the types array; for example, "types": ["node"] (if you use builtin modules like buffer or path, to load @types/node), "types": ["node", "jest"] (if you're also writing jest tests); or even just "types": [] to prevent typescript from auto-loading any package that is not directly imported or /// <reference types="..." /> from your code.

I can't really say whether having a @types/styled-components-native would be better; it would be unusual at the very least, and maybe remove the need for the compilerOptions.types "workaround", but IMO setting compilerOptions.types to only the packages whose types you need to be autoloaded (without imports) is a best practice.

To summarize, the issue is TypeScript is automatically loading the @types/react-native types, despite you not directly or indirectly referencing them at all, because the default behavior is to load all @types/* packages. Setting compilerOptions.types prevents that default and loads only the packages you list + the packages you import.

I can't believe this is still an issue! Ran into this issue last summer, I just updated the package because I assumed this would have been fixed since then 😠

who is the maintainer of the @types/styled-components ? because we need someone new

Proposal of @Jessidhia with compilerOptions.types worked for me. Thank you very much! I do also see this as best practice. Until now I experienced no disadvantages. I could imagine that it's faster, also.

@sbusch the disadvantage is that if you use compilerOptions.types all of your typings will need to be listed here, as anything not included in this list will be excluded. So, for packages that are installed which provide typings, you'll need to manage this config manually

Yeah, Listing all types in types is not an option.

If you import something from a modules you still get the TypeScript typings. The types option is for auto-importing types for the global declarations. This isn't needed very often, so it should be not too bad to manually add those modules to types. That's how I understand it. Our quite large TS codebase with very strict TS settings still worked after setting types array to [].

See for example https://stackoverflow.com/a/59030291

the disadvantage is that if you use compilerOptions.types all of your typings will need to be listed here, as anything not included in this list will be excluded. So, for packages that are installed which provide typings, you'll need to manage this config manually

As @sbush said, this is not true. That option is just for global types, imported libs' typings will be used with no problems. @Jessidhia's proposal is harmless.

I don't think a single package should force consumers to break with convention which is to leave that field alone. As with everything else, that's not a solution but a workaround.

Not sure if someone already answered the case when you have a mono repo Lerna + yarn workspaces (too many answers). For this case, you can make use of the no-hoist property more info in yarn website

in practices in your package.json file:

"workspaces": {
  "packages": ["packages/*"],
  "nohoist": ["**/react-native", "**/react-native/**"]
}

🙏🏻@types/styled-components": "4.1.8"🙏🏻

The solution @nahumzs proposes works if you are using yarn monorepos. In this case, we keep react-native from polluting the global node_packages folder, preventing duplicates that in turn throw errors.

At what point do we just say that there are more React Web users than React Native users, and strip React Native support out?

Has there been any progress on this issue? We are currently on version 4.1.8 of @types/styled-components because we are unable to update without a resolution or utilizing a work around, such as deleting the node_modules/@types/react-native in an npm post install command.

Oh f**k, this issue causes me really a lot of pain.

Now I'm incurring the problem describe in here. So, if I upgrade to newer Typescript I can't even use @types/[email protected]. 😡😡😡 WTH.

Anyway, this seems to be a duplicate of https://github.com/DefinitelyTyped/DefinitelyTyped/issues/33015.

In Appsome Solutions we had the same problem and we workarounded it with "skipLibCheck": true, rule in a tsconfig.json file.

In case like anyone felt the same: I didn't want to enable skipLibCheck just to work around this issue. But I changed my mind now that a recent change enabled skipLibCheck for fresh TypeScript projects - apparently for performance reasons, but could imagine also because of issues like the one we're seeing here.

maybe somebody ok with a very dirty hack, you can just add to your package.json script's section:

"postinstall": "rm -rf node_modules/@types/react-native"

Not a great solution, but this should work.

OMG, this issue is still actual even for 5.1.1

1- Add a .yarnclean in the project root.
2- Insert the following content: @types/react-native.

This resolved here at least while I wait for a oficial solution.

This has been going on for over 1.5 years, now. Anyway, I think my issue is related and I'm getting a lot more "Duplicate identifiers" errors. 36 in total.

tsconfig.json

{
  "compilerOptions": {
    "allowJs": true,
    "baseUrl": ".",
    "esModuleInterop": true,
    "isolatedModules": true,
    "jsx": "react",
    "module": "CommonJS",
    "moduleResolution": "Node",
    "noEmit": true,
    "sourceMap": true,
    "target": "ES6"
  },
  "include": [
    "src/**/*"
  ],
}

Result from compiling with tsc:

Total: 38 errors. Only 2 of them are from my actual project source src/**.* files. The other 36 errors are from .d.ts conflicts caused by @types/styled-components.

Note: If I add the "skipLibCheck": true flag, the errors go away. Also if I remove @types/styled-components, the errors are also gone.

I won't post the full log here, but here are some examples.

error TS2300: Duplicate identifier 'AbortController'.
../../../AppData/Roaming/npm/node_modules/typescript/lib/lib.dom.d.ts:1939:11
../../../AppData/Roaming/npm/node_modules/typescript/lib/lib.dom.d.ts:1950:13 
node_modules/@types/react-native/globals.d.ts:363:15

error TS2300: Duplicate identifier 'AbortSignal'. 
../../../AppData/Roaming/npm/node_modules/typescript/lib/lib.dom.d.ts:1960:11 
node_modules/@types/react-native/globals.d.ts:350:15
../../../AppData/Roaming/npm/node_modules/typescript/lib/lib.dom.d.ts:1972:13

error TS2300: Duplicate identifier 'FormData'. 
../../../AppData/Roaming/npm/node_modules/typescript/lib/lib.dom.d.ts:5548:11
node_modules/@types/react-native/globals.d.ts:40:15
../../../AppData/Roaming/npm/node_modules/typescript/lib/lib.dom.d.ts:5558:13

error TS2300: Duplicate identifier 'URL'.
error TS2300: Duplicate identifier 'URLSearchParams'.
error TS2300: Duplicate identifier 'RequestInfo'.
error TS2300: Duplicate identifier 'XMLHttpRequestResponseType'.

error TS2717: Subsequent property declarations must have the same type.  Property 'body' 
must be of type 'string | ArrayBuffer | ArrayBufferView | Blob | FormData | URLSearchParams | ReadableStream<Uint8Array> | null | undefined', 
but here has type 'string | ArrayBuffer | DataView | Int8Array | Uint8Array | Uint8ClampedArray | Int16Array | ... 8 more ... | undefined'. 

error TS2717: Subsequent property declarations must have the same type.  Property 'signal' must be of type 'AbortSignal | null | undefined', but here has type 'AbortSignal | undefined'.

error TS2300: Duplicate identifier 'RequestInfo'.

The solution I'm adopting at this point is to remove @types/styled-components and to move on with my project (which is a React web app).