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

Pareil ici

Pourquoi @types/react-native a-t-il été ajouté ? J'ai un projet web React, pourquoi dois-je installer des dactylographies que je n'utilise pas ?

Corrigé par set compilerOptions.types manuellement

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

J'ai le même problème aussi.

Même problème ici.
Comme j'ai plusieurs définitions de type dans mon projet, j'ai fixé la dépendance @types/styled-components à une version précédente.

Je pense que l'ajout explicite de types à tsconfig.json est une mauvaise solution.
Il serait préférable de séparer les types pour styled-components pour le web et pour natif.

J'ai un problème avec ce FormData, j'utilise typescript: 3.3.333 voici mon package.json et tsconfig.json

FORFAIT 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" ] }

J'ai le même problème. Heureusement, j'ai pu surmonter le problème en verrouillant la version de @types/styled-components sur 4.1.8

Idem ici, je devais soit revenir à une version précédente, soit ajouter un script de post-installation pour supprimer react-native de node_modules

Comment êtes-vous même censé utiliser des composants stylisés sur le Web si ses dépendances entrent en conflit par défaut avec les bibliothèques dom ? !
C'est insensé!

J'ai le même problème et j'ai aussi remarqué que tous les auteurs n'avaient pas été prévenus. Il manque ces deux là : @eps1lon @flavordaaave

@ArthurBrito merci, la liste des auteurs a été mise à jour.

Ce problème m'arrive aussi. @types/react-native ne doit pas être une dépendance dans les projets Web. Ces types doivent être séparés

Pour autant que je sache, cela a été causé par #32843 qui a été publié en tant que 4.1.9 . Ce commentaire le confirme.

J'ai posté un commentaire dans ce fil en faisant référence à ce problème.

/cc @minestarks

la correction de la version 4.1.8 a fonctionné pour moi

Y a-t-il un PR ici qui aborde ce problème? Étrange, vous ne pouvez pas utiliser de composants stylisés dans les projets Web.

J'ai le même problème, en effet il s'agit de @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]

Une mise à jour du problème ?

Créez un fichier .yarnclean avec le contenu suivant :

@types/react-native

résout le problème 🎉

Six mois et toujours pas de mises à jour pour ce problème ?

Vraiment pas de mise à jour ???

À mon avis, la meilleure solution serait de faire de @types/react-native une dépendance entre pairs, mais à ma connaissance, types-publisher ne les prend pas en charge pour le moment. L'un des responsables peut-il vérifier que j'ai bien raison et que peerDep est une solution ? Je pourrais peut-être passer du temps le week-end à ajouter le support peerDep à types-publisher, si nous sommes prêts à partir.

A mon avis, la meilleure solution serait de faire de @types/react-native une dépendance entre pairs

Hmm, si @types/react-native est un service homologue, je devrais le déclarer en tant que dépendance afin d'utiliser @types/styled-components dans un projet non-React Native. Ce n'est pas idéal.

Idéalement, @types/react-native ne serait pas requis par un projet non-React Native ; et je ne devrais surtout pas avoir à le déclarer comme dépendance.

Voulez-vous en faire une dépendance facultative ?

@paulmelnikow , oui, tu as raison, j'ai confondu les deux. Vous n'auriez toujours pas besoin de déclarer @types/react-native tant que dépendance pour utiliser @types/styled-components , mais vous recevrez un avertissement embêtant, donc optionnelDeps est une meilleure solution, bien sûr. types-publisher ne les supporte pas aussi bien, et je vais essayer de me renseigner

La rétrogradation vers "@types/styled-components": "4.0.0" a résolu le problème.

Non, ça ne résout pas. Il balaie le problème sous le tapis

Non, ça ne résout pas. Il balaie le problème sous le tapis

Disons qu'il compile à nouveau ? ;-)

Créez un fichier .yarnclean avec le contenu suivant :

@types/react-native

résout le problème 🎉

Existe-t-il un équivalent avec npm ?

des progrès sur cette question?
cela rend les composants stylisés inutilisables avec le script dactylographié.

En plongeant dans le code réel de ce référentiel, vous pouvez clairement voir que @types/react-native est UNIQUEMENT nécessaire dans le .d.ts réel et le fichier de test pour l'intégration React Native. Je pense qu'une solution plus appropriée serait que tout ce qui est lié à React Native soit divisé en son propre sous-module/optionnel/dépendance de pair, cohérent avec le comportement de fonctionnement réel de styled-components , vous importez styled-components/native si vous voulez les trucs React Native. Vous n'importez pas styled-components et n'obtenez pas toute la jungle de React Native pendant l'exécution, donc en important seulement styled-components je ne devrais pas obtenir également toute la jungle de @types/react-native types.

Je pense que pour l'instant, l'intégration react-native devrait être supprimée de la version publiée par NPM de ce package et publiée comme son propre package. Dans l'état actuel des choses, cela est cassé de manière embarrassante et rend TypeScript dans son ensemble mauvais

Veuillez s'il vous plaît résoudre ce problème. Retirez les types natifs dès que possible. Cela rend ce qui est un excellent projet de dactylographie presque inutilisable.

En plongeant dans le code réel de ce référentiel, vous pouvez clairement voir que @types/react-native est UNIQUEMENT nécessaire dans le .d.ts réel et le fichier de test pour l'intégration React Native. Je pense qu'une solution plus appropriée serait que tout ce qui est lié à React Native soit divisé en son propre sous-module/optionnel/dépendance de pair, cohérent avec le comportement de fonctionnement réel de styled-components , vous importez styled-components/native si vous voulez les trucs React Native. Vous n'importez pas styled-components et n'obtenez pas toute la jungle de React Native pendant l'exécution, donc en important seulement styled-components je ne devrais pas obtenir également toute la jungle de @types/react-native types.

??

Je pense que pour l'instant, l'intégration react-native devrait être supprimée de la version publiée par NPM de ce package et publiée comme son propre package.

Je pense que cela pourrait être une solution, mais je me demande également s'il pourrait y avoir un moyen de les expédier tous les deux dans le même colis, comme c'était le cas de #32843, sans causer ce problème.

Juste une note amicale pour dire que la meilleure façon de résoudre ce problème est de creuser et d'ouvrir un PR avec une solution, ou de trouver quelqu'un spécifiquement investi dans les composants stylisés qui peut réparer.

DefinitelyTyped fournit un service génial à la communauté des paquets et il y a des mainteneurs ici, bien que leur travail ne soit pas de maintenir tous les types. Serrer le poing à ce projet (ou à TypeScript) ne va pas aider.

je passe à l' émotion
Ils incluent leurs propres définitions dactylographiées et ont exactement la même interface, donc la migration est facile à trouver et à remplacer.
De plus, la taille du paquet est un peu plus petite.

Que diriez-vous de simplement annuler les modifications introduites dans #32843, car cela a cassé les frappes pour environ 90% des utilisateurs et les a forcés à utiliser une version obsolète ou certains hacks mentionnés dans ce fil.

Que diriez-vous de simplement annuler les modifications introduites dans #32843, car cela a cassé les frappes pour environ 90% des utilisateurs et les a forcés à utiliser une version obsolète ou certains hacks mentionnés dans ce fil.

Cela pourrait être une solution raisonnable si cela améliore le fonctionnement des frappes pour la grande majorité des utilisateurs. Je ne sais pas avec certitude si le PR serait approuvé ou non, mais si vous pensez que c'est la meilleure solution, n'hésitez pas à faire un PR.

Je pense que si ce retour devait être fait, ce serait d'ajouter des notes au package sur la façon de le faire fonctionner avec react-native par la suite. Je ne l'ai pas essayé, mais il serait probablement possible pour les utilisateurs natifs de réagir de copier et coller les saisies supprimées dans leur projet avec une déclaration declare module et que les choses continuent de fonctionner. Bien qu'évidemment, il soit dommage de devoir obliger les utilisateurs natifs à réagir.

Bien que tbh, j'aimerais que l'équipe TypeScript puisse fournir des conseils officiels sur la façon de gérer des problèmes comme ceux-ci, car il semble que quelqu'un finisse par "perdre" dans toutes les solutions.

OMI, cela devrait être annulé - principalement parce que l'écosystème des composants de style Web est plus grand.

Je ne connais plus tous les détails de son fonctionnement, mais auparavant, pour React Native, vous obteniez un ensemble différent de types en utilisant un chemin différent, ce qui me semblait être un bon compromis. Hrm, on dirait que c'est ce qui apporte. ça y retourne.

Je me demande s'il pourrait y avoir un moyen d'avoir un module ambiant que les gens importent via une importation triple barre oblique qui ajoute les types spécifiques natifs de réaction?

+1 ici, mais pas seulement pour me plaindre, s'il y a un plan d'action, je veux participer et aider à résoudre ce problème.

Je suis venu ici, je suis allé ajouter mon plus un à certains des commentaires. J'ai réalisé que je l'avais déjà fait... la dernière fois que j'ai rencontré ce problème.

Et c'est pourquoi j'ai supplié d'autres mainteneurs de bibliothèques de conserver leurs types. Cela force la bibliothèque à se mettre à jour en ligne avec leurs types. J'aime que def typed ait aidé la communauté à bien des égards, mais lorsque les mainteneurs de la lib ont la possibilité de le saisir eux-mêmes (ou même de le réécrire dans ts), cela rend le monde plus sûr.

Je restais également calme et calme à propos de ce problème car j'ai pu contourner ce problème via un clone local, mais je pense que les gens du monde entier ont suffisamment souffert de ce problème (plus de 6 mois). Je veux que ce problème critique et paralysant soit résolu et permettre aux utilisateurs de scripts non avertis en matière de technologie de revenir en arrière.

Y a-t-il des PR en attente d'approbation ? Dois-je mettre une seule ligne de modification de code qui supprime la dépendance globale react-native non valide (comme je l'ai fait dans mon référentiel npm privé) ?

De plus, y a-t-il une raison pour laquelle react-native doit être installé et entrer en conflit avec les espaces de noms globaux ? S'il vous plaît, participez et partagez vos pensées. (Mais je me demande si ces personnes qui ont involontairement cassé notre travail liraient un jour ce numéro, car elles seraient aussi heureuses qu'elles devraient n'avoir aucune idée de nos dommages. Je ne peux pas dire que je n'ai jamais été à l'autre bout d'une telle affaire avant.)

De plus, comment les autres packages traitent-ils ce genre de problème ? Je n'en ai aucune idée, j'hésite donc un peu à faire un _"simple"_ PR qui renverse ce problème.

Bien que je pense que ce changement devrait être annulé, nous n'avons pas eu besoin d'activer skipLibCheck pour que cela fonctionne : https://github.com/DefinitelyTyped/DefinitelyTyped/issues/33311#issuecomment -466731156 . S'il vous plaît ne le faites pas.

Je ne pense pas que l'annulation de ce changement soit une bonne option. Beaucoup de gens ont besoin de frappes pour react-native et nous devons corriger ce qui provoque une erreur et ne pas supprimer toutes les frappes react-native.

Et s'il n'y a pas de solution pour le moment ? Nous devrions au moins fournir une version pour les utilisateurs non natifs car elle est complètement cassée pour le moment et l'est depuis un certain temps, et j'oserais supposer que les utilisateurs non natifs sont également majoritaires.

des mises à jour à ce sujet ?

Les personnes react-native peuvent les installer manuellement.
Pourquoi ont-ils besoin du tout?

Je ne pense pas que l'annulation de ce changement soit une bonne option. Beaucoup de gens ont besoin de frappes pour react-native et nous devons corriger ce qui provoque une erreur et ne pas supprimer toutes les frappes react-native.

Les personnes qui ont besoin de saisies pour react-native devraient les obtenir en installant @types/react-native .

Je suis toujours fermement convaincu que tout ce qui concerne react-native devrait être supprimé de @types/styled-components et déplacé vers un autre package/chemin, par exemple @types/styled-components/native pour être cohérent avec la façon dont les gens sont réellement utiliser styled-components ; les personnes qui veulent react-native support import styled from 'styled-components/native' , vous n'obtenez pas l'intégralité de toute la jungle de react-native en faisant import styled from 'styled-components' dans un site Web projet, donc les packages @types/ associés ne devraient pas se comporter différemment

J'ai essayé de résoudre ce problème de manière plus systémique au cours du week-end, ce qui pourrait fonctionner pour n'importe quel référentiel qui encapsule les types pour le Web + réagir natif. https://github.com/microsoft/types-publisher/pull/655

comment cela n'a-t-il pas été résolu...

Sérieusement? Toujours pas de solution ?

@givethemheller @sanex3339 il y a un correctif dans les travaux et la discussion à https://github.com/microsoft/types-publisher/pull/655

Comme solution temporaire, supprimez simplement @types/react-native de node_modules :
rm -rf node_modules/@types/react-native
et ajoutez-le à .yarnclean
@types/react-native

Avec la sortie de TypeScript 3.7, nous nous trouvons maintenant dans une situation où les utilisateurs de 3.7 sont _forcés_ de mettre à niveau leurs définitions de type, car la version 4.1.8 qui fonctionnait auparavant est désormais incompatible avec TS 3.7, mais la seule version compatible avec TS 3.7 est complètement cassée. pour chaque développeur React-web (qui doit sûrement être la grande majorité écrasante). ??

La solution .yarnclean contournement compilerOptions n'est pas du tout une solution évolutive et à long terme.

Je ne sais pas quelle est la meilleure solution ici. Comme pis-aller, je suis définitivement en faveur de la publication d'une version séparée qui exclut spécifiquement les choses react-native .

En tant qu'utilisateur sans fil, vous pouvez contourner ce problème en ajoutant ceci à vos scripts npm :

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

Forcera NPM à supprimer les types natifs immédiatement après les avoir installés. Encore une solution de contournement pour ce qui ne devrait même pas être un problème, mais cela fonctionne.

Je m'ajoute ici aussi. Nous avons besoin d'une solution, mieux que d'éditer beaucoup de scripts de post-installation...

Ce problème affecte essentiellement tous les utilisateurs de scripts dactylographiés de composants stylisés depuis plus d'un an (!!!).
Avons-nous une solution officielle pour cela (sans compter les hacks avec .yarnclean) ? Y a-t-il des bloqueurs ?

J'ai envie de diviser cela en deux packages (ou potentiellement trois, un de base avec des éléments communs à la fois pour réagir natif et réagir, un pour réagir et un autre pour RN, et faire en sorte que les deux derniers utilisent le premier avec les éléments communs) serait être le moyen le plus simple et le plus rapide de gérer cela.

Je suis plus que disposé à aider, si nous ne manquons que de contributeurs, je veux juste qu'il soit plus facile d'utiliser à la fois les composants stylisés et le script dactylographié, sans avoir à bidouiller des trucs 😄

Je veux juste qu'il soit plus facile d'utiliser à la fois les composants stylisés et le script dactylographié, sans avoir à bidouiller des trucs 😄

Cogner! Il doit y avoir une meilleure implémentation de la définition de type...

J'ai supprimé @types/react-native de mes node_modules et j'ai toujours la même erreur. Pourquoi même avec le hack ?

@ArnaudJeannin si vous l'avez supprimé manuellement à la main, il sera rajouté à chaque fois que vous exécuterez npm i / yarn

Pour rendre la suppression persistante via les installations, supprimez-la via NPM postinstall conformément à mon commentaire précédent ou ajoutez-la à .yarnclean si vous utilisez Yarn devrait fonctionner correctement.

Ce que j'ai fait ne conviendra pas à tout le monde, mais j'ai "résolu" ce problème en passant des composants stylisés à l' @types .

Comme indiqué ci-dessus, le changement de bibliothèque CSS ne conviendra pas à de nombreux projets, mais pour moi, le changement était plus facile que de se disputer avec des problèmes de style de composants TS. YMMV.

Solution de contournement plus simple pour les utilisateurs de yarn , qui vous permettra d'utiliser la version actuelle de styled-components. Dans package.json :

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

Configurez un package de ne rien faire qui est la cible de la résolution ci-dessus :

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

Travaille pour moi.

@arimah @GabrielDuarteM , pouvez-vous expliquer votre downvote ? Avez-vous essayé ceci et trouvé que cela ne fonctionnait pas? Veuillez commenter afin que je puisse aider et que d'autres puissent en bénéficier si c'est le cas. Cela semble beaucoup moins invasif que la seule autre solution de contournement disponible à ce stade (un script de post-installation pour supprimer le module de type). Ou s'il y a un fort point négatif à cette solution de contournement que je n'ai pas réalisé, j'aimerais réviser ou supprimer le commentaire.

@jamietre Je pense que les

@jamietre Je pense que les

Je ne savais pas que les solutions de contournement étaient mal vues. Je les trouve toujours très utiles en attendant une vraie solution. C'est un problème depuis plus d'un an. et le travail reste à faire. ??

@jamietre Je pense que c'est juste que vous l'avez

@jamietre Je pense que c'est juste que vous l'avez

J'ai changé la "solution" en "solution de contournement"... vraiment, j'essaie juste d'aider les gens à pouvoir utiliser des composants stylisés avec un script dactylographié. Les votes négatifs signifient que cela ne fonctionne pas. Cela ne semble pas utile de chipoter sur la sémantique, mais bien sûr.

Dans Appsome Solutions, nous avons eu le même problème et nous l'avons contourné avec la règle "skipLibCheck": true, dans un fichier tsconfig.json.

@pumanitro Comme beaucoup d'autres choses suggérées, ce n'est malheureusement pas une solution mais une simple solution de contournement.

@SamHH Mot modifié résolu en contournement.
C'est comme ça que ça se fait dans CRA avec tapuscrit, mais vous avez raison ce n'est pas une solution. Pourtant, cela peut aider les gens.

Republier mon commentaire de https://github.com/DefinitelyTyped/DefinitelyTyped/pull/32843#issuecomment -605921101

La solution de contournement consiste à avoir un tableau compilerOptions.types dans votre tsconfig.json qui empêche le script dactylographié de lire automatiquement chaque paquet @types/* lors de la vérification de type. Typescript n'importera automatiquement que les types de packages nommés dans le tableau types ; par exemple, "types": ["node"] (si vous utilisez des modules intégrés comme buffer ou path , pour charger @types/node ), "types": ["node", "jest"] (si vous ré écrivant également des tests de plaisanterie); ou même juste "types": [] pour empêcher le dactylographe de charger automatiquement tout package qui n'est pas directement importé ou /// <reference types="..." /> partir de votre code.

Je ne peux pas vraiment dire si avoir un @types/styled-components-native serait mieux ; ce serait pour le moins inhabituel, et peut-être supprimer le besoin de la "solution de contournement" compilerOptions.types , mais l'OMI définit compilerOptions.types uniquement sur les packages dont vous devez charger automatiquement les types (sans import s) est une pratique exemplaire.

Pour résumer, le problème est que TypeScript charge automatiquement les types @types/react-native , bien que vous ne les référenciez pas du tout directement ou indirectement, car le comportement par défaut est de charger tous les packages @types/* . La définition de compilerOptions.types empêche cette valeur par défaut et ne charge que les packages que vous répertoriez + les packages que vous import .

Je ne peux pas croire que ce soit toujours un problème ! J'ai rencontré ce problème l'été dernier, je viens de mettre à jour le package car je pensais que cela aurait été corrigé depuis lors 😠

qui est le mainteneur des @types/styled-components ? parce que nous avons besoin de quelqu'un de nouveau

La proposition de @Jessidhia avec compilerOptions.types fonctionné pour moi. Merci beaucoup! Je vois aussi cela comme une bonne pratique. Jusqu'à présent, je n'ai connu aucun inconvénient. Je pourrais imaginer que c'est plus rapide, aussi.

@sbusch l'inconvénient est que si vous utilisez compilerOptions.types toutes vos saisies devront être répertoriées ici, car tout ce qui n'est pas inclus dans cette liste sera exclu. Ainsi, pour les packages installés qui fournissent des saisies, vous devrez gérer cette configuration manuellement

Oui, la liste de tous les types dans les types n'est pas une option.

Si vous importez quelque chose à partir d'un module, vous obtenez toujours les saisies TypeScript. L'option types est destinée aux types d'importation automatique pour les déclarations globales. Ce n'est pas nécessaire très souvent, il ne devrait donc pas être trop mal d'ajouter manuellement ces modules à types . C'est comme ça que je le comprends. Notre base de code TS assez volumineuse avec des paramètres TS très stricts fonctionnait toujours après avoir défini le tableau types sur [] .

Voir par exemple https://stackoverflow.com/a/59030291

l'inconvénient est que si vous utilisez compilerOptions.types toutes vos saisies devront être répertoriées ici, car tout ce qui n'est pas inclus dans cette liste sera exclu. Ainsi, pour les packages installés qui fournissent des saisies, vous devrez gérer cette configuration manuellement

Comme l'a dit @sbush , ce n'est pas vrai. Cette option est juste pour les types globaux, les typages de import ed libs seront utilisés sans problème. La proposition de @Jessidhia est inoffensive.

Je ne pense pas qu'un seul emballage devrait forcer les consommateurs à rompre avec la convention qui consiste à laisser ce domaine tranquille. Comme pour tout le reste, ce n'est pas une solution mais une solution de contournement.

Je ne sais pas si quelqu'un a déjà répondu au cas lorsque vous avez un dépôt mono Lerna + yarn workspaces (trop de réponses). Dans ce cas, vous pouvez utiliser la propriété no-hoist plus d'informations sur le site Web de laine

dans les pratiques dans votre fichier package.json :

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

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

La solution @nahumzs propose des travaux si vous utilisez des monorepos de fil. Dans ce cas, nous empêchons react-native de polluer le dossier global node_packages, évitant ainsi les doublons qui génèrent à leur tour des erreurs.

À quel moment disons-nous simplement qu'il y a plus d'utilisateurs de React Web que d'utilisateurs de React Native, et supprimons-nous la prise en charge de React Native ?

Y a-t-il eu des progrès sur cette question? Nous sommes actuellement sur la version 4.1.8 de @types/styled-components car nous ne pouvons pas mettre à jour sans résolution ou en utilisant une solution de contournement, telle que la suppression de node_modules/@types/react-native dans une commande de post-installation npm.

Oh putain, ce problème me fait vraiment mal.

Maintenant, je rencontre le problème décrit ici . Donc, si je passe à une version plus récente de Typescript, je ne peux même pas utiliser @types/[email protected] . WTH.

Quoi qu'il en soit, cela semble être un doublon de https://github.com/DefinitelyTyped/DefinitelyTyped/issues/33015.

Dans Appsome Solutions, nous avons eu le même problème et nous l'avons contourné avec la règle "skipLibCheck": true, dans un fichier tsconfig.json.

Au cas où quelqu'un aurait ressenti la même chose : je ne voulais pas activer skipLibCheck juste pour contourner ce problème. Mais j'ai changé d'avis maintenant qu'un changement récent activait skipLibCheck pour de nouveaux projets TypeScript - apparemment pour des raisons de performances, mais on pourrait aussi l'imaginer à cause de problèmes comme celui que nous voyons ici.

peut-être que quelqu'un est d'accord avec un hack très sale, vous pouvez simplement ajouter à la section de votre script package.json :

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

Ce n'est pas une bonne solution, mais cela devrait fonctionner.

OMG, ce problème est toujours d'actualité même pour 5.1.1

1- Ajoutez un .yarnclean à la racine du projet.
2- Insérez le contenu suivant : @types/react-native .

Cela a été résolu ici au moins pendant que j'attends une solution officielle.

Cela dure depuis plus d'un an et demi maintenant. Quoi qu'il en soit, je pense que mon problème est lié et je reçois beaucoup plus d'erreurs "Identifiants en double". 36 au 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/**/*"
  ],
}

Résultat de la compilation avec tsc :

Total : 38 erreurs. Seuls 2 d'entre eux proviennent de mes fichiers source de projet src/**.* . Les 36 autres erreurs proviennent de conflits .d.ts causés par @types/styled-components .

Remarque : Si j'ajoute le drapeau "skipLibCheck": true , les erreurs disparaissent. De plus, si je supprime @types/styled-components , les erreurs disparaissent également.

Je ne publierai pas le journal complet ici, mais voici quelques exemples.

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'.

La solution que j'adopte à ce stade est de supprimer @types/styled-components et de poursuivre mon projet (qui est une application Web React).