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

Hier gilt das gleiche

Warum wurde @types/react-native überhaupt hinzugefügt? Ich habe ein React-Webprojekt, warum muss ich Eingaben installieren, die ich nicht verwende?

Behoben durch manuelles Setzen von CompilerOptions.types

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

Ich habe das gleiche Problem auch.

Gleiches Problem hier.
Da ich mehrere Typdefinitionen in meinem Projekt habe, habe ich die Abhängigkeit von @types/styled-components auf eine frühere Version festgelegt.

Ich denke, das explizite Hinzufügen von Typen zu tsconfig.json ist eine schlechte Lösung.
Es wäre besser, die Typen für styled-components für Web und für native zu trennen.

Ich habe ein Problem mit diesen FormData, ich verwende typescript: 3.3.333 hier ist mein package.json und tsconfig.json

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

Ich habe das gleiche Problem. Glücklicherweise konnte ich das Problem lösen, indem ich die Version von @types/styled-components auf 4.1.8 sperrte

Auch hier musste ich entweder zu einer früheren Version zurückkehren oder ein Postinstall-Skript hinzufügen, um React-Native aus node_modules zu entfernen

Wie soll man überhaupt styled-Komponenten im Web verwenden, wenn deren Abhängigkeiten standardmäßig mit den dom-Libs kollidieren?!
Das ist verrückt!

Ich habe das gleiche Problem und mir ist auch aufgefallen, dass nicht alle Autoren benachrichtigt wurden. Diese beiden fehlen: @eps1lon @flavordaaave

@Arthurbrito danke, die Liste der Autoren wurde aktualisiert.

Dieses Problem tritt bei mir auch auf. @types/react-native sollte in Webprojekten keine Abhängigkeit sein. Diese Typen sollten getrennt werden

Soweit ich das beurteilen kann, wurde dies durch #32843 verursacht, das als 4.1.9 veröffentlicht wurde . Dieser Kommentar bestätigt dies .

Ich habe in diesem Thread einen Kommentar zu diesem Thema gepostet.

/cc @minestarks

Version 4.1.8 zu reparieren hat bei mir funktioniert

Gibt es hier eine PR, die dieses Problem anspricht? Seltsam, dass Sie in Webprojekten keine Styled-Komponenten verwenden können.

Habe das gleiche Problem, tatsächlich geht es um @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]

Irgendein Update zum Thema?

Erstellen Sie eine .yarnclean Datei mit folgendem Inhalt:

@types/react-native

behebt das Problem

Ein halbes Jahr und immer noch keine Updates zu diesem Thema?

Wirklich kein Update???

Meiner Meinung nach wäre die beste Lösung, @types/react-native zu einer Peer-Abhängigkeit zu machen, aber meines Wissens unterstützt types-publisher diese derzeit nicht. Kann einer der Betreuer bitte bestätigen, dass ich tatsächlich Recht habe und peerDep eine Lösung ist? Ich kann vielleicht am Wochenende etwas Zeit damit verbringen, den Typs-Publisher peerDep-Unterstützung hinzuzufügen, wenn wir bereit sind.

Meiner Meinung nach wäre die beste Lösung, @types/react-native zu einer Peer-Abhängigkeit zu machen

Hmm, wenn @types/react-native ein Peer-Dep ist, müsste ich es als Abhängigkeit deklarieren, um @types/styled-components in einem Nicht-React Native-Projekt zu verwenden. Das ist nicht ideal.

Idealerweise wird @types/react-native von einem Nicht-React Native-Projekt nicht benötigt; und vor allem sollte ich es nicht als Abhängigkeit _deklarieren_ müssen.

Wollen Sie es zu einer optionalen Abhängigkeit machen?

@paulmelnikow , ja du hast recht, ich habe die beiden verwechselt. Sie müssten @types/react-native immer noch nicht als Abhängigkeit deklarieren, um @types/styled-components , aber Sie erhalten eine lästige Warnung, daher ist optionalDeps natürlich die bessere Lösung. types-publisher unterstützt sie auch nicht, und ich werde versuchen, es zu überprüfen

Downgrade auf "@types/styled-components": "4.0.0" hat das Problem behoben.

Nein, es löst sich nicht. Es fegt das Problem unter den Teppich

Nein, es löst sich nicht. Es fegt das Problem unter den Teppich

Sagen wir, es wird noch einmal kompiliert? ;-)

Erstellen Sie eine .yarnclean Datei mit folgendem Inhalt:

@types/react-native

behebt das Problem

Gibt es ein Äquivalent zu npm?

irgendwelche Fortschritte zu diesem Thema?
es macht gestylte Komponenten mit Typoskript unbrauchbar.

Wenn Sie in den eigentlichen Code dieses Repositorys eintauchen, können Sie deutlich sehen, dass @types/react-native NUR in der tatsächlichen .d.ts und Testdatei für die React Native-Integration benötigt wird. Ich denke, eine angemessenere Lösung wäre es, alles, was mit React Native zu tun hat, in seine eigene Submodul- / optionale / Peer-Abhängigkeit aufzuteilen, im Einklang mit dem Verhalten von styled-components , das Sie importieren styled-components/native wenn Sie das React Native-Zeug wollen. Sie importieren nicht styled-components und erhalten auch den gesamten Dschungel von React Native-Sachen zur Laufzeit. Wenn Sie also nur styled-components importieren, sollte ich nicht auch den gesamten Dschungel von @types/react-native -Typen.

Ich denke, dass die reaktive Integration in der Zwischenzeit aus der von NPM veröffentlichten Version dieses Pakets gelöscht und als eigenes Paket veröffentlicht werden sollte. So wie es aussieht ist das peinlich kaputt und lässt TypeScript als Ganzes schlecht aussehen

Bitte beheben Sie dieses Problem. Nehmen Sie die nativen Typen so schnell wie möglich heraus. Dies macht ein ansonsten hervorragendes Tippprojekt nahezu unbrauchbar.

Wenn Sie in den eigentlichen Code dieses Repositorys eintauchen, können Sie deutlich sehen, dass @types/react-native NUR in der tatsächlichen .d.ts und Testdatei für die React Native-Integration benötigt wird. Ich denke, eine angemessenere Lösung wäre es, alles, was mit React Native zu tun hat, in seine eigene Submodul- / optionale / Peer-Abhängigkeit aufzuteilen, im Einklang mit dem Verhalten von styled-components , das Sie importieren styled-components/native wenn Sie das React Native-Zeug wollen. Sie importieren nicht styled-components und erhalten auch den gesamten Dschungel von React Native-Sachen zur Laufzeit. Wenn Sie also nur styled-components importieren, sollte ich nicht auch den gesamten Dschungel von @types/react-native -Typen.

👍

Ich denke, dass die reaktive Integration in der Zwischenzeit aus der von NPM veröffentlichten Version dieses Pakets gelöscht und als eigenes Paket veröffentlicht werden sollte.

Ich denke, das könnte eine Lösung sein, frage mich aber auch, ob es eine Möglichkeit geben könnte, beide im selben Paket zu versenden, wie es in #32843 der Fall war, ohne dieses Problem zu verursachen.

Nur eine freundliche Anmerkung, um zu sagen, dass der beste Weg, dieses Problem zu beheben, darin besteht, eine PR mit einer Lösung zu öffnen oder jemanden zu finden, der speziell in Styled Components investiert hat und der es beheben kann.

DefinitivTyped bietet der Paket-Community einen großartigen Service und es gibt hier Betreuer, deren Aufgabe jedoch nicht darin besteht, alle Typen zu pflegen. Bei diesem Projekt (oder bei TypeScript) die Faust zu schütteln, wird nicht helfen.

Ich wechsle zu Emotion
Sie enthalten ihre eigenen Typoskript-Definitionen und haben genau die gleiche Schnittstelle, sodass die Migration leicht zu finden und zu ersetzen ist.
Außerdem ist die Paketgröße etwas kleiner.

Wie wäre es, wenn wir die in #32843 eingeführten Änderungen einfach rückgängig machen, da dies die Eingaben für etwa >90% der Benutzer brach und sie zwang, veraltete Versionen oder einige in diesem Thread erwähnte Hacks zu verwenden.

Wie wäre es, wenn wir die in #32843 eingeführten Änderungen einfach rückgängig machen, da dies die Eingaben für etwa >90% der Benutzer brach und sie zwang, veraltete Versionen oder einige in diesem Thread erwähnte Hacks zu verwenden.

Dies könnte eine vernünftige Lösung sein, wenn die Eingaben für die überwiegende Mehrheit der Benutzer besser funktionieren. Ich weiß nicht genau, ob die PR genehmigt wird oder nicht, aber wenn Sie der Meinung sind, dass dies die beste Lösung ist, können Sie gerne eine PR machen.

Ich denke, wenn diese Wiederherstellung durchgeführt werden sollte, müssten dem Paket einige Hinweise hinzugefügt werden, wie man es anschließend mit Reaktiv-Native zum Laufen bringt. Ich habe es nicht ausprobiert, aber es wäre wahrscheinlich für reaktive Benutzer möglich, die entfernten Eingaben mit einer declare module Deklaration in ihr Projekt zu kopieren und einzufügen, und die Dinge funktionieren weiterhin. Obwohl es natürlich eine Schande ist, reaktive Benutzer dazu zwingen zu müssen, dies zu tun.

Trotzdem würde ich mich freuen, wenn das TypeScript-Team eine offizielle Anleitung zum Umgang mit Problemen wie diesen geben könnte, da es so aussieht, als würde jemand bei allen Lösungen "verlieren".

IMO, dies sollte rückgängig gemacht werden - hauptsächlich, weil das Ökosystem der webgestylten Komponenten größer ist.

Ich kenne nicht mehr alle Details, wie es funktioniert, aber früher war es so, dass man für React Native einen anderen Satz von Typen erhielt, indem man einen anderen Pfad verwendete, was mir wie ein guter Kompromiss erschien. Hrm, sieht so aus, als ob das was bringt. das wieder hinein.

Ich frage mich, ob es vielleicht eine Möglichkeit geben könnte, ein Ambient-Modul zu haben, das die Leute über einen dreifachen Schrägstrich importieren, der die reaktiven spezifischen Typen hinzufügt?

+1 hier, aber nicht nur beschweren, wenn es einen Aktionsplan gibt, möchte ich teilnehmen und helfen, dieses Problem zu lösen.

Ich kam hierher, um mein Plus zu einigen der Kommentare hinzuzufügen. Mir wurde klar, dass ich dies bereits getan hatte ... als ich das letzte Mal auf dieses Problem gestoßen bin.

Und deshalb habe ich andere Bibliotheksverwalter gebeten, ihre Typen zu behalten. Es zwingt die Bibliothek, inline mit ihren Typen zu aktualisieren. Ich finde es toll, dass def typed der Community in vielerlei Hinsicht geholfen hat, aber wenn die Lib-Betreuer die Möglichkeit haben, es selbst einzugeben (oder sogar in ts umzuschreiben), macht es die Welt sicherer.

Ich blieb auch bei diesem Problem gelassen und ruhig, da ich dieses Problem mit einem lokalen Klon umgehen konnte, aber ich denke, dass Menschen auf der ganzen Welt genug unter diesem Problem gelitten haben (mehr als 6 Monate). Ich möchte, dass dieses kritische und lähmende Problem behoben wird und nicht technisch versierte Typoskriptbenutzer wieder einsteigen können.

Gibt es PRs, die auf Genehmigung warten? Sollte ich eine einzelne Codezeile ändern, die eine ungültige globale Abhängigkeit von react-native (wie ich es in meinem privaten npm-Repository getan habe)?

Gibt es auch einen Grund, warum react-native installiert werden sollte und mit globalen Namespaces in Konflikt steht? Bitte melden Sie sich an und teilen Sie Ihre Gedanken mit. (Aber ich frage mich, ob die Leute, die unabsichtlich unsere Arbeit unterbrachen, diese Ausgabe jemals lesen würden, da sie so glücklich wären, wie sie sollten, keine Ahnung von unserem Schaden zu haben. Ich kann nicht sagen, dass ich nie am anderen Ende eines solchen Falles war Vor.)

Und wie gehen andere Pakete mit dieser Art von Problem um? Ich habe keine Ahnung davon und zögere so ein bisschen, eine _"einfache"_ PR zu machen, die dieses Problem umkehrt.

Obwohl ich denke, dass diese Änderung rückgängig gemacht werden sollte, mussten wir skipLibCheck nicht aktivieren, damit dies funktioniert: https://github.com/DefinitelyTyped/DefinitelyTyped/issues/33311#issuecomment -466731156 . Bitte nicht.

Ich glaube nicht, dass es eine gute Option ist, diese Änderung rückgängig zu machen. Viele Leute brauchen Eingaben für Reactive-Native und wir sollten das Problem beheben, das einen Fehler verursacht, und nicht alle reaktiven Eingaben entfernen.

Und wenn es im Moment keine Lösung gibt? Wir sollten zumindest eine Version für nicht-native Benutzer bereitstellen, da sie im Moment völlig kaputt ist und seit einiger Zeit, und ich wage zu vermuten, dass auch nicht-native Benutzer die Mehrheit sind.

irgendwelche Updates dazu?

@dawick- Leute, die für react-native tippen müssen, können sie manuell installieren.
Warum brauchen sie überhaupt?

Ich glaube nicht, dass es eine gute Option ist, diese Änderung rückgängig zu machen. Viele Leute brauchen Eingaben für Reactive-Native und wir sollten das Problem beheben, das einen Fehler verursacht, und nicht alle reaktiven Eingaben entfernen.

Leute, die Eingaben für react-native benötigen, sollten diese durch die Installation von @types/react-native .

Ich bin immer noch stark von der Position , dass alles im Zusammenhang react-native aus gelöscht werden soll @types/styled-components und zog in einen anderen Paket / Pfad zB @types/styled-components/native , um im Einklang mit , wie die Menschen tatsächlich verwende styled-components ; Leute, die react-native Unterstützung wünschen, erhalten diese explizit, indem sie import styled from 'styled-components/native' . Sie erhalten nicht den gesamten react-native Dschungel, wenn Sie import styled from 'styled-components' in einem Web tun Projekt, also sollten sich die zugehörigen @types/ Pakete nicht anders verhalten

Ich habe am Wochenende versucht, dies systemisch zu beheben, was für jedes Repository funktionieren könnte, das Typen für Web + React native umschließt. https://github.com/microsoft/types-publisher/pull/655

wie wurde das nicht behandelt...

Ernsthaft? Immer noch keine Lösung?

@givethemheller @sanex3339 es gibt einen Fix in Arbeit und Diskussion unter https://github.com/microsoft/types-publisher/pull/655

Als vorübergehende Lösung entfernen Sie einfach @types/react-native aus node_modules:
rm -rf node_modules/@types/react-native
und füge es zu .yarnclean
@types/react-native

Mit der Veröffentlichung von TypeScript 3.7 befinden wir uns nun in einer Situation, in der Benutzer von 3.7 _gezwungen_ sind, ihre Typdefinitionen zu aktualisieren, da die zuvor funktionierende v4.1.8 jetzt nicht mit TS 3.7 kompatibel ist, aber die einzige Version, die mit TS 3.7 kompatibel ist, ist völlig kaputt für jeden React-Webentwickler (was sicherlich die überwiegende, überwältigende Mehrheit sein muss). 😕

Der .yarnclean Workaround reicht wahrscheinlich für diejenigen aus, die Yarn verwenden, was weniger als alle umfasst. Und das Ändern von compilerOptions ist überhaupt keine skalierbare, langfristige Lösung.

Ich weiß nicht, was hier die beste Lösung ist. Als Notlösung bin ich definitiv dafür, eine separate Version zu veröffentlichen, die die Dinge react-native ausdrücklich ausschließt.

Als Nicht-Yarn-Benutzer können Sie dies umgehen, indem Sie dies zu Ihren npm-Skripten hinzufügen:

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

Veranlasst NPM, die nativen Typen sofort nach der Installation zu löschen. Immer noch ein hackiger Workaround für das, was nicht einmal ein Problem sein sollte, aber es funktioniert.

Füge mich auch hier hinzu. Wir brauchen eine Lösung, die besser ist, als viele Postinstall-Skripte zu bearbeiten...

Dieses Problem betrifft seit mehr als einem Jahr (!!!) praktisch alle Typoskript-Benutzer von Styled-Komponenten.
Haben wir dafür eine offizielle Lösung (die Hacks mit .yarnclean nicht mitgezählt)? Gibt es Blocker?

Ich möchte dies in zwei Pakete aufteilen (oder möglicherweise drei, ein Basispaket mit gemeinsamem Material für React-Native und Reaction, eines für React und ein weiteres für RN, und die beiden letzteren verwenden das erste mit dem Common Zeug). der einfachste und schnellste Weg, damit umzugehen.

Ich bin mehr als bereit zu helfen, wenn uns nur Mitwirkende fehlen, ich möchte nur, dass es einfacher ist, sowohl gestylte Komponenten als auch Typoskript zusammen zu verwenden, ohne etwas herumhacken zu müssen 😄

Ich möchte nur, dass es einfacher ist, sowohl gestylte Komponenten als auch Typoskript zusammen zu verwenden, ohne etwas herumhacken zu müssen 😄

Stoßen! Es muss eine bessere Typdefinitionsimplementierung geben...

Ich habe @types/react-native aus meinen node_modules entfernt und erhalte immer noch den gleichen Fehler. Warum überhaupt mit dem Hack?

@ArnaudJeannin Wenn Sie es manuell von Hand gelöscht haben, wird es jedes Mal wieder hinzugefügt, wenn Sie npm i / yarn ausführen

Um die Löschung durch Installationen dauerhaft zu machen, sollte entweder das Entfernen über NPM postinstall gemäß meinem vorherigen Kommentar oder das Hinzufügen zu .yarnclean funktionieren, wenn Sie Yarn verwenden.

Was ich gemacht habe, ist nicht für jeden geeignet, aber ich habe dieses Problem "gelöst", indem ich von gestylten Komponenten auf Emotion umgestiegen bin. Meine Verwendung einer der beiden Bibliotheken ist ziemlich einfach - ich schließe nur Komponenten mit CSS ein und erb Stile -, aber ich fand, dass Emotion eine ähnliche API wie gestylte Komponenten für die Funktionen hat, die ich brauchte. Es war ein einfacher Übergang. Ich habe nach 6 Monaten noch keine nennenswerten Probleme gehabt. Emotion enthält integrierte TS-Eingaben, sodass es keine Synchronisierungsprobleme mit @types .

Wie oben erwähnt, ist das Wechseln von CSS-Bibliotheken für viele Projekte nicht angemessen, aber für mich war der Wechsel einfacher als das Ringen mit TS-Problemen mit Stilkomponenten. YMMV.

Einfachere Problemumgehung für yarn Benutzer, mit der Sie die aktuelle Version von Styled-Komponenten verwenden können. In package.json:

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

Richten Sie ein Do-Nothing-Paket ein, das das Ziel der obigen Auflösung ist:

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

Funktioniert bei mir.

@arimah @GabrielDuarteM , kannst du deine Ablehnung erklären? Haben Sie dies versucht und festgestellt, dass es nicht funktioniert? Bitte kommentieren Sie, damit ich helfen kann und andere davon profitieren könnten. Dies scheint viel weniger invasiv zu sein als die einzige andere Problemumgehung, die zu diesem Zeitpunkt verfügbar ist (ein Postinstall-Skript zum Löschen des Typmoduls). Oder wenn diese Problemumgehung stark negativ ist, die ich nicht erkannt habe, würde ich den Kommentar gerne überarbeiten oder entfernen.

@jamietre Ich glaube, die Ablehnungen sind, dass dies zwar funktionieren könnte, dies jedoch nicht die richtige Lösung ist und nichts an der Tatsache ändert, dass die Typen für

@jamietre Ich glaube, die Ablehnungen sind, dass dies zwar funktionieren könnte, dies jedoch nicht die richtige Lösung ist und nichts an der Tatsache ändert, dass die Typen für

Wusste nicht, dass Workarounds verpönt sind. Ich finde sie immer sehr hilfreich, während ich auf eine echte Lösung warte. Das ist seit über einem Jahr ein Thema. und die Arbeit muss noch erledigt werden. 🤷♂

@jamietre Ich denke, es ist nur so, dass Sie es als "Lösung" eingerahmt haben, was es nicht ist, und es als solches zu gestalten, könnte den Betreuern den Eindruck vermitteln, dass dies nicht immer noch ein lächerliches Problem ist, das die Mehrheit ihrer Benutzer betrifft.

@jamietre Ich denke, es ist nur so, dass Sie es als "Lösung" eingerahmt haben, was es nicht ist, und es als solches zu gestalten, könnte den Betreuern den Eindruck vermitteln, dass dies nicht immer noch ein lächerliches Problem ist, das die Mehrheit ihrer Benutzer betrifft.

"Lösung" in "Problemumgehung" geändert ... wirklich, ich versuche nur, den Leuten zu helfen, stilisierte Komponenten mit Typoskript zu verwenden. Die Downvotes implizieren, dass es nicht funktioniert. Scheint nicht hilfreich zu sein, über Semantik zu streiten, aber sicher.

In Appsome Solutions hatten wir das gleiche Problem und wir haben es mit der Regel "skipLibCheck": true, in einer Datei tsconfig.json umgangen.

@pumanitro Wie viele andere vorgeschlagene Dinge ist dies leider keine Lösung, sondern eine reine Problemumgehung.

@SamHH Wort gelöst in
So wird es in CRA mit Typoskript gemacht, aber Sie haben Recht, es ist keine Lösung. Dennoch kann es den Menschen helfen.

Reposting meines Kommentars von https://github.com/DefinitelyTyped/DefinitelyTyped/pull/32843#issuecomment -605921101

Die Problemumgehung besteht darin, ein compilerOptions.types Array in Ihrem tsconfig.json dass Typescript automatisch jedes einzelne @types/* Paket bei der Typprüfung liest. Typescript importiert automatisch nur die Pakettypen, die im types Array genannt werden; zum Beispiel "types": ["node"] (wenn Sie eingebaute Module wie buffer oder path , um @types/node zu laden), "types": ["node", "jest"] (wenn Sie re auch Scherztests schreiben); oder auch nur "types": [] , um zu verhindern, dass Typescript automatisch ein Paket lädt, das nicht direkt importiert wird, oder /// <reference types="..." /> aus Ihrem Code.

Ich kann nicht wirklich sagen, ob es besser wäre, ein @types/styled-components-native zu haben; es wäre zumindest ungewöhnlich und würde vielleicht die compilerOptions.types "Abhilfe" überflüssig machen, aber IMO setzt compilerOptions.types nur auf die Pakete, deren Typen automatisch geladen werden müssen (ohne import s) ist eine bewährte Methode.

Zusammenfassend lässt sich sagen, dass TypeScript automatisch die @types/react-native Typen lädt, obwohl Sie sie weder direkt noch indirekt referenzieren, da das Standardverhalten darin besteht, alle @types/* Pakete zu laden. Das Setzen von compilerOptions.types verhindert diesen Standard und lädt nur die Pakete, die Sie auflisten + die Pakete, die Sie import .

Ich kann nicht glauben, dass das immer noch ein Problem ist! Ich bin letzten Sommer auf dieses Problem gestoßen, ich habe das Paket gerade aktualisiert, weil ich davon ausgegangen bin, dass dies seitdem behoben wäre 😠

Wer ist der Betreuer der @types/styled-components ? weil wir jemanden neu brauchen

Der Vorschlag von @Jessidhia mit compilerOptions.types hat für mich funktioniert. Vielen Dank! Ich sehe dies auch als Best Practice. Bisher habe ich keine Nachteile erfahren. Ich könnte mir vorstellen, dass es auch schneller geht.

@sbusch der Nachteil ist, dass, wenn Sie compilerOptions.types alle Ihre Eingaben hier aufgelistet werden müssen, da alles, was nicht in dieser Liste enthalten ist, ausgeschlossen wird. Bei installierten Paketen, die Eingaben bereitstellen, müssen Sie diese Konfiguration manuell verwalten

Ja, alle Typen in Typen aufzulisten ist keine Option.

Wenn Sie etwas aus einem Modul importieren, erhalten Sie immer noch die TypeScript-Typisierungen. Die Option types dient zum automatischen Importieren von Typen für die globalen Deklarationen. Dies wird nicht sehr oft benötigt, daher sollte es nicht allzu schlimm sein, diese Module manuell zu types hinzuzufügen. So verstehe ich es. Unsere ziemlich große TS-Codebasis mit sehr strengen TS-Einstellungen funktionierte immer noch, nachdem das types Array auf [] .

Siehe zum Beispiel https://stackoverflow.com/a/59030291

der Nachteil ist, dass, wenn Sie compilerOptions.types alle Ihre Eingaben hier aufgelistet werden müssen, da alles, was nicht in dieser Liste enthalten ist, ausgeschlossen wird. Bei installierten Paketen, die Eingaben bereitstellen, müssen Sie diese Konfiguration manuell verwalten

Wie @sbush sagte, ist dies nicht wahr. Diese Option ist nur für globale Typen, import ed libs' Typisierungen werden ohne Probleme verwendet. @Jessidhias Vorschlag ist harmlos.

Ich glaube nicht, dass ein einziges Paket Verbraucher dazu zwingen sollte, mit Konventionen zu brechen, die dieses Feld allein lassen. Wie bei allem anderen ist das keine Lösung, sondern ein Workaround.

Nicht sicher, ob jemand den Fall bereits beantwortet hat, wenn Sie ein Mono-Repo haben Lerna + yarn workspaces (zu viele Antworten). In diesem Fall können Sie die Eigenschaft no-hoist Weitere Informationen auf der Garn-Website

in der Praxis in Ihrer package.json Datei:

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

@types/styled-components": "4.1.8"

Die von @nahumzs vorgeschlagene Lösung funktioniert, wenn Sie Garnmonorepos verwenden. In diesem Fall verhindern wir, dass Reactive-Native den globalen node_packages-Ordner verschmutzt, wodurch Duplikate verhindert werden, die wiederum Fehler auslösen.

An welchem ​​Punkt sagen wir einfach, dass es mehr React Web-Benutzer als React Native-Benutzer gibt, und streichen die React Native-Unterstützung weg?

Gab es in dieser Frage Fortschritte? Wir arbeiten derzeit an Version 4.1.8 von @types/styled-components, da wir ohne eine Lösung oder einen Workaround, wie das Löschen von node_modules/@types/react-native in einem npm post install-Befehl, nicht aktualisieren können.

Oh verdammt, dieses Problem bereitet mir wirklich große Schmerzen.

Jetzt habe ich das hier beschriebene Problem. Wenn ich also auf ein neueres Typescript aktualisiere, kann ich nicht einmal @types/[email protected] . 😡😡😡 WTH.

Wie auch immer, dies scheint ein Duplikat von https://github.com/DefinitelyTyped/DefinitelyTyped/issues/33015 zu sein.

In Appsome Solutions hatten wir das gleiche Problem und wir haben es mit der Regel "skipLibCheck": true, in einer Datei tsconfig.json umgangen.

Für den Fall, dass es jemandem ähnlich ging: Ich wollte skipLibCheck nicht aktivieren, nur um dieses Problem zu umgehen. Aber ich habe meine Meinung geändert, da eine kürzliche Änderung skipLibCheck für neue TypeScript-Projekte aktiviert hat - anscheinend aus Leistungsgründen, könnte mir aber auch aufgrund von Problemen wie dem, was wir hier sehen, vorstellen.

Vielleicht ist jemand mit einem sehr schmutzigen Hack in Ordnung, Sie können einfach den Abschnitt Ihres package.json Skripts hinzufügen:

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

Keine gute Lösung, aber das sollte funktionieren.

OMG, dieses Problem ist auch für 5.1.1 noch aktuell

1- Fügen Sie ein .yarnclean im Projektstamm hinzu.
2- Fügen Sie den folgenden Inhalt ein: @types/react-native .

Dies hat sich hier zumindest gelöst, während ich auf eine offizielle Lösung warte.

Das geht jetzt schon über 1,5 Jahre so. Wie auch immer, ich denke, mein Problem hängt zusammen und ich erhalte viel mehr Fehler "Doppelte Bezeichner". 36 insgesamt.

tsconfig.json

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

Ergebnis beim Kompilieren mit tsc :

Gesamt: 38 Fehler. Nur 2 davon stammen aus meinen tatsächlichen Projektquelldateien src/**.* . Die anderen 36 Fehler stammen von .d.ts Konflikten, die durch @types/styled-components .

Hinweis: Wenn ich das Flag "skipLibCheck": true hinzufüge, verschwinden die Fehler. Auch wenn ich @types/styled-components entferne, sind die Fehler auch weg.

Ich werde hier nicht das vollständige Protokoll veröffentlichen, aber hier sind einige Beispiele.

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

Die Lösung, die ich an dieser Stelle annehme, besteht darin, @types/styled-components zu entfernen und mit meinem Projekt (das eine React-Webanwendung ist) fortzufahren.