Is there a conflict between @types/node and @types/react-native?

[bherila]

• I tried using the @types/node and @types/react-native package and had problems.
• I tried using the latest stable version of tsc. https://www.npmjs.com/package/typescript
• I have a question that is inappropriate for StackOverflow. (Please ask any appropriate questions there).
• Mention the authors (see Definitions by: in index.d.ts) so they can respond.
  • Authors: @alloy @gyzerok

Both of the modules seem to define require and this results in some compliation trouble:

../node_modules/@types/node/index.d.ts(49,13): error TS2451: Cannot redeclare block-scoped variable 'global'.
../node_modules/@types/node/index.d.ts(73,13): error TS2300: Duplicate identifier 'require'.
../node_modules/@types/react-native/index.d.ts(8541,11): error TS2451: Cannot redeclare block-scoped variable 'global'.
../node_modules/@types/react-native/index.d.ts(8542,14): error TS2300: Duplicate identifier 'require'.

Any tips/workarounds?

[gyzerok]

@bherila can you, please, create a SSCCE repository which one can run by himself?

[alloy]

It’s true, there are conflicts between the two. RN provides some features that people are used to from Node (e.g. require), however it is definitely not a full-fledged Node environment, so using the Node typings isn’t really correct.

In the end, we solved it by removing the Node typings and just sprinkle a few typings here and there where they were really needed, e.g. in our Jest setup which does run on Node: artsy/emission@25f296c#diff-0b93f41d9b1048bf2a2e50b4036a898aR2

[rawrmaan]

@bherila I run this bash script whenever I do a full npm install (and in my npm postinstall script so I can deploy to Heroku). It replaces the global definitions in the RN typings with nonsense so everything compiles nicely: https://gist.github.com/rawrmaan/be47e71bd0df3f7493ead6cefd6b400c

[bherila]

Also, for some reason updating to the latest typings of each, and the latest typescript made the problem go away, although I still feel like it isn't "solved" per se :(

But I'll close the issue for the time being. That script also looks helpful, thanks @rawrmaan

[alloy]

Good to know 👍

[dieseldjango]

I'm running into this problem with my react-native project via a transitive dependency ing react-native-code-push, which through a chain of dependencies installs a package developed in TypeScript for node, which installs @types/node as its own dependency. I hacked around this by removing @types/node in my postinstall script. I could probably also use @rawrmaan's hack, but I'm wondering what the "right" way to deal with this would be.

Should the package that pulls in @types/node not declare it as a dependency? That would leave types in their own type definition unresolved until the consumer of the package pulls in @types/node. They could declare @types/node as a peerDependency, but then non-node consumers such as myself would get a bogus missing peer warning. Or is this a problem for the react-native-code-push package, which needs to be somehow refactored to eliminate the node dependency?

[chetmurphy]

I'm still hitting the problem with typescript 2.5.2, @types/react-native 0.48.0, and @types/node 8.0.22. I'm removing the errors by commenting out the declarations in @types/node and @types/react-native one by one (running tsc each time) starting with the top most error.

[jcampbell05]

This is a huge problem with my app which is cross platform since electron pulls it in. One solution is to structure your project in a way to have the dependencies not conflict (have electron and RN as separate packages)

Easier said than done.

[evanjmg]

+1 - please fix this. getting with latest everything

[ou2s]

+1 I have the issue with RN 0.48.4

[jcampbell05]

Is there a way of maybe getting react native to depend on the node type definition instead of rolling it's own ?

[alloy]

Alas, RN can’t pull in the node definitions, because RN doesn’t run inside node and so TS wouldn’t be able to tell you that certain APIs are not available.

We maintainers of the RN typings are all for accepting a solution, but please note that +1s are not going to help, the RN typings are completely driven by the needs of the maintainers and contributors.

[alloy]

@dieseldjango Alas, the only way to currently do it is indeed to specify it as a peer dependency and leave it up to user to decide what is right for their project.