Definitelytyped: [@types/react-redux] 'hoist-non-react-statics' hat kein exportiertes Mitglied 'NonReactStatics'

Huch. Ich habe in dieser Änderung eine Abhängigkeit von @types/hoist-non-react-statics , aber nicht als Abhängigkeit hinzugefügt. Dieses Problem ist, dass ich nicht sicher bin, wo ich es als Abhängigkeit deklarieren soll, da die Typen nur von den Typen abhängen.

@JounQin , können Sie mir helfen zu verstehen, wie ich das beheben kann. Müssen wir ///<reference hinzufügen oder etwas zum package.json hinzufügen?

Als vorübergehende Problemumgehung können Sie npm install --dev @types/hoist-non-react-statics zu Ihrem Projekt hinzufügen.

Ich könnte mich irren, aber ich denke, das Problem ist vielleicht einfacher,

import { NonReactStatics } from 'hoist-non-react-statics';

sollte sein

import NonReactStatics from 'hoist-non-react-statics';

Ein Downgrade auf @types/react-redux 7.0.1 ist eine schnelle Lösung, bis dies behoben ist.

Ich habe dieses Problem heute auch. Downgrade auf 7.0.1 hat geholfen

Hier gilt das gleiche.

Huch. Ich habe in dieser Änderung eine Abhängigkeit von @types/hoist-non-react-statics , aber nicht als Abhängigkeit hinzugefügt

DefinitelyTyped fügte @types/hoist-non-react-statics automatisch als Abhängigkeit zu @types/react-redux , aber (anscheinend) reichte das nicht aus, damit Ihre Eingaben funktionieren.

Als vorübergehende Problemumgehung können Sie npm install --dev @types/hoist-non-react-statics zu Ihrem Projekt hinzufügen.

Nein, das wird nicht funktionieren, da diese Abhängigkeit bereits automatisch von DefinitelyTyped hinzugefügt wird, aber es reicht nicht aus, dass TS Ihre Eingaben korrekt behandelt.

Ich vermute das Problem, dass TS die Existenz des hoist-non-react-statics Moduls nicht kennt, da das hoist-react-statics Paket selbst nicht in node_modules vorhanden ist (es ist eine Schande, dass TS die Modulexistenz nicht von @types/hoist-non-react-statics ableiten kann manuelle Installation von hoist-non-react-statics dafür sorgt, dass Ihre Eingaben korrekt funktionieren .

Also, @jamesreggio, ich denke, Sie müssen das Paket hoist-non-react-statics als Abhängigkeit zu package.json von @types/react-redux hinzufügen, um dieses Problem zu beheben.

@surgeboris auf [email protected] und @types/[email protected] hinzugefügt, ein Problem behoben

Der Fix funktioniert bei mir nicht wirklich. Vielleicht mache ich etwas falsch. Mit Garn 1.13

Alles klar, danke für eure Geduld.

Ich habe eine Lösung gefunden und eine PR geöffnet: #33919.

Wenn Sie den Typdefinitionsexport im Node-Stil (mit export = ) verwenden, ist der richtige Importweg anscheinend mit import [name] = require([package name]) . Mir sind die Nuancen dieser Import/Export-Muster eher unbekannt, und ich bin nur vage zuversichtlicher, dass ich sie jetzt verstehe 😆

Hoffentlich können die Betreuer von DefinitielyTyped dies so schnell wie möglich zusammenführen und veröffentlichen. Sorry nochmal für den Rückschritt.

Leider hat dies das Problem für mich selbst mit 7.0.4 , das kürzlich veröffentlicht wurde, nicht behoben

Es sieht so aus, als ob die explizite Abhängigkeit von @types/hoist-non-react-statics noch fehlt.

eigentlich nein - ein neues npm i @types/react-redux installiert @types/hoist-non-react-statics . Ich sehe kein Problem?

Ja, die Abhängigkeit ist definitiv in package.json :

  "dependencies": {
    "@types/hoist-non-react-statics": "*",
    "@types/react": "*",
    "redux": "^4.0.0"
  },

Wenn Sie immer noch Probleme haben, sollten Sie überprüfen, ob die richtigen Versionen von allem installiert wurden.

(Insbesondere wird die Abhängigkeit als * , sodass Sie möglicherweise eine ältere Version von @types/hoist-non-react-statics , der möglicherweise der Typ fehlt, der npm als die Abhängigkeit erfüllend zählt?)

Das Problem ist also etwas nuanciert.

Das hoist-non-react-statics Paket enthielt seine eigenen hyper-einfachen Eingaben von v2.2.0 bis v3.0.0 , und wenn die Version von hoist-non-react-statics in Ihrem Projektstamm darin aufgelöst wird Bereich, tritt dieser Fehler auf, da die paketlokalen Eingaben Vorrang vor @types/hoist-non-react-statics .

Es gibt zwei sofortige Problemumgehungen:

1. Fügen Sie Ihrem Projekt hoist-non-react-statics@^3.3.0 als Abhängigkeit hinzu.
2. Wenn Sie Garn verwenden, fügen Sie Ihrem package.json eine Auflösungsüberschreibung hinzu:
   "resolutions": { "hoist-non-react-statics": "^3.3.0" }

Beides ist nicht optimal, da sich die meisten Entwickler (zu Recht) der Existenz von hoist-non-react-statics nicht bewusst sind.

Ich bin mir nicht sicher, was hier der optimale Ansatz wäre, aber ich vermute, dass, wenn wir eine bestimmte Versionsspezifikation für @types/hoist-non-react-statics innerhalb von package.json für @types/react-redux auflisten könnten, wir die Auswirkungen mildern könnte.

@weswigham — wissen Sie, ob es möglich ist, die * durch eine Abhängigkeit von @types/hoist-non-react-statics mit >=3.3.0 zu ersetzen?

@weswigham — wissen Sie, ob es möglich ist, die

Wenn Sie es explizit in package.json hinzufügen, könnte es funktionieren? AFAIK Sie können keine Versionen für implizite oder auf Pfadzuordnungen basierende Abhängigkeiten hartcodieren, aber ich könnte mich irren.

@sandersn weißt du mehr?

Ich habe gerade eine PR geöffnet, die eine bestimmte Version von @types/hoist-non-react-statics im package.json . Hoffentlich funktioniert das? Kann bestimmt nicht schaden.

@weswigham , macht es Ihnen

https://github.com/DefinitelyTyped/DefinitelyTyped/pull/33979

Ich weiß nicht, ob das die richtige Lösung ist. Ich habe eine direkte Abhängigkeit von hoist-non-react-statics@latest hinzugefügt und alle Probleme behoben.

Ugh, @weswigham + @sandersn – ich bin mir nicht sicher, was ich tun soll. Der Travis-Build ist fehlgeschlagen, weil ich eine bestimmte Versionsspezifikation für @types/hoist-non-react-statics hinzugefügt habe. Siehe den Fehler hier .

Es stimmt, dass meine Änderung in @types/react-redux ein Minimum von 3.3.0 von @types/hoist-non-react-statics @types/react-redux _erfordert_, also denke ich, dass ich in der Lage sein sollte, diese Einschränkung auszudrücken. Können Sie mir helfen zu verstehen, wie das geht? (Soll ich tun, was die Fehlermeldung sagt, und es zu dependenciesWhitelist.txt in types-publisher hinzufügen? Das scheint ein zu großer Hammer zu sein.)

Es ist kein allzu großer Hammer - Ihr Problem ist ziemlich genau das, was die Log-Meldung beschreibt (außer wir haben dann auch wieder auf die zugrunde liegenden Paket- und nicht Versandarten zurückgegriffen, ganz die Saga).

Cool, ich habe eine PR bereit, die auf types-publisher : https://github.com/Microsoft/types-publisher/pull/595

@weswigham – kannst du es landen?

Es wurde um 3:06 PDT (40 Minuten vor diesem Kommentar oder so) veröffentlicht.

Okay Leute, probiert @types/[email protected] und lasst es mich wissen, wenn ihr immer noch kaputt seid.

Immer noch das gleiche Problem mit @types/[email protected] . Die einzige Lösung, die für mich funktioniert hat, ist, hoist-non-react-statics in meinem Projekt manuell zu erfordern

Abgeordnet, immer noch defekt in @types/ react-redux @

@jamesreggio @weswigham Ich bin mir nicht sicher, ob du die Kommentare gesehen hast, aber pinge dich, damit wir sicher sind, dass du es gesehen hast

Ja, danke, hatte ich. Ich habe heute Nachmittag bei Cisco React unterrichtet, als das in die Klasse geriet. Nach einer kurzen Überprüfung und fand ich diesen Thread, hatte ich sie zurück auf 7.0.1 und es funktionierte OK. Aber ich habe eine leichte Seltsamkeit. Wenn ich Hebezeug-Nicht-Reaktions-Statiken hinzufüge, funktioniert es, wie oben beschrieben. Wenn ich hoist-non-react-statics deinstalliere, funktioniert es weiterhin. Vielleicht gibt es also eine echte Abhängigkeit, die dort aufgenommen wird, aber auch dann bestehen bleibt, wenn Sie dieses Paket entfernen. Wenn ich node_modules und package-lock.json lösche und ohne Hoist neu installiere, ist es wieder kaputt. Ich muss jetzt hier raus, also kann ich jetzt nicht mehr Zeit damit verbringen, tiefer zu graben. Jemand anderes könnte es sowieso schneller finden, da es besser auf das Paket abgestimmt ist.

Ich werde mich morgen nochmal damit befassen, aber ehrlich gesagt brauche ich etwas Hilfe
von einem Experten. Die Feinheiten des TS-Modulsystems verblüffen mich. ich fühle
als hätte ich hier alles richtig gemacht...

Können diejenigen von Ihnen, die das Problem haben, bitte eine Zusammenfassung Ihrer
package-lock.json oder garn.lock? Ich habe das Gefühl, dass dies ein Problem sein könnte
auf die ungewöhnliche Tatsache, dass die Hub-Non-React-Statik eigene Typisierungen beinhaltete
für einen kurzen Zeitraum in der Vergangenheit.

Am Do, 21. März 2019 um 20:03 Uhr schrieb Joel Mussman [email protected] :

Ja, danke, hatte ich. Ich habe heute Nachmittag bei Cisco React unterrichtet, als das
die Klasse gebissen. Nach einer kurzen Überprüfung und ich fand diesen Thread, hatte ich sie zurück
bis 7.0.1 und es funktionierte OK. Aber ich habe eine leichte Seltsamkeit. Wenn ich hinzufüge
heben-nicht-reagieren-statik funktioniert wie oben beschrieben. Wenn ich deinstalliere
heben-nicht-reagieren-statik es funktioniert weiter. Also vielleicht gibt es eine echte
Abhängigkeit, die dort aufgenommen wird, aber bleibt, auch wenn Sie sie entfernen
dieses Paket. Wenn ich node_modules und package-lock.json lösche und
ohne Hebezeug neu installieren, es ist wieder kaputt. Ich muss jetzt hier raus,
Daher kann ich jetzt nicht mehr Zeit damit verbringen, tiefer zu graben.
Jemand anderes könnte es sowieso schneller finden, wenn er mehr mit dem im Einklang ist
Paket.

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/DefinitelyTyped/DefinitelyTyped/issues/33690#issuecomment-475477877 ,
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/AAyLva1P2ZGe86669tG7yu7fe1yMWWf-ks5vZEgHgaJpZM4bjI1Z
.

Hier ist mein package-lock.json : https://github.com/hellomouse/GNS/blob/greenkeeper/default/%40types/react-redux-7.0.5/dashboard/package-lock.json

Hallo James,

OK, ich verstehe, was in meinem Klassenprojekt falsch ist. Ich weiß noch nicht, wie ich es beheben kann. Aber ich werde veröffentlichen, was ich weiß, und vielleicht kann Ihnen jemand bei Definitely Typed helfen.

React-Router wird vor React-Redux vom vorherigen Lab installiert. Die aktuelle Version von React-Router (bis vor 4 Tagen) war 4.3.1 und hat eine Abhängigkeit von [email protected]. Da niemand sonst eine Abhängigkeit von hoist-non-react-statics hatte, wurde das Paket gemäß den Regeln auf der obersten Ebene von node_modules installiert. Jetzt ist [email protected] installiert. Es hängt von der [email protected] ab. Da sich 2.2.5 jedoch bereits auf der obersten Ebene befindet, wird 3.3.0 in den Ordner node_modules UNDER React-Redux gelegt. Es scheint also, dass die Abhängigkeit in @types/react-redux von @types/ hoist-non- react-statics@

Andere zuvor beschriebene Probleme können diesem Szenario sehr ähnlich sein.

Verwandte Frage: Wie sollen wir wissen, welche Version von @types/react-redux welcher Version von React-Redux zugeordnet ist? Da die Zahlen nicht übereinstimmen, bin ich dort verloren.

Ich habe eine PR erstellt, um dieses Problem zu beheben #34090

Sollte dieses Problem nicht erneut geöffnet werden, da das zugrunde liegende Problem mit Version 7.0.5 noch nicht behoben ist?
(ohne @types/hoist-non-react-statics + hoist-non-react-statics zu den devDependencies hinzuzufügen)

100% stimmen zu, dass dies nicht geschlossen werden sollte, aber immer noch kaputt ist, es sei denn, Sie fügen manuell zu devDependances hinzu

Ich habe den richtigen Fix eingereicht, den die Leute hier von Anfang an anscheinend ignoriert haben: #34406

Jetzt, da der PR zusammengeführt ist, müssen die Reak-Redux-Typen die Abhängigkeit von der Hubwerk-Nicht-Reakt-Statik aktualisieren?

Ich glaube schon. Aber ich denke, Sie können damit davonkommen, die Abhängigkeit zu entfernen (deinstallieren) und erneut hinzuzufügen

Von: Maurice [email protected]
Gesendet: Donnerstag, 4. April 2019 15:53:32
An: Definitiv typisiert/Definitiv typisiert
CC: wolfy1339; Handbuch
Betreff: Re: [DefinitelyTyped/DefinitelyTyped] [@types/react-redux] 'hoist-non-react-statics' hat keinen exportierten Member 'NonReactStatics' (#33690)

Jetzt, da der PR zusammengeführt ist, müssen die Reak-Redux-Typen die Abhängigkeit von der Hubwerk-Nicht-Reakt-Statik aktualisieren?

—
Sie erhalten dies, weil Sie diesen Thread abonniert haben.
Antworten Sie direkt auf diese E-Mail, zeigen Sie sie auf GitHub https://github.com/DefinitelyTyped/DefinitelyTyped/issues/33690#issuecomment-480039685 an oder schalten Sie den Thread stumm https://github.com/notifications/unsubscribe-auth/AEYfFbvvu7_1ZrU42jUUxkBX3k5uwlg

Du meinst die React-Redux-Tipps? Ich werde das versuchen.

@wolfy1339 https://github.com/DefinitelyTyped/DefinitelyTyped/pull/34406 schien das Problem für mich nicht zu beheben. Ich denke, das liegt daran, dass hoist-non-react-statics innerhalb von @types/hoist-non-react-statics ( node_modules/@types/hoist-non-react-statics/node_modules/hoist-non-react-statics ) installiert wird, also verwendet TS immer noch die Typen meiner Root-Version ( node_modules/hoist-non-react-statics ).

An dieser Stelle war es einen Versuch wert. Hat noch jemand eine Idee?

@weswigham Können Sie dieses Problem erneut öffnen?

Hatte ein ähnliches Problem - die Verwendung von Garn anstelle von npm zum Installieren von Abhängigkeiten hat mein Problem behoben. Poste als Randnotiz, weil ihr es vielleicht als Workaround ausprobieren könnt.

@alan-mroczek Wir verwenden Garn, also hilft das nicht. Hier muss etwas anderes im Spiel sein. (Datei sperren?)

Ich weiß nicht, ob ich das genaue Problem verstehe, aber die Lösung, die für mich mit Garn funktionierte, bestand darin, der package.json ein Auflösungsfeld hinzuzufügen.

"resolutions": {
  "hoist-non-react-statics": ">=3.3.0"
}

Dieses Problem ist für "@types/react-redux": "7.0.8", immer noch aktiv und das Festlegen von "Auflösungen" ist keine universelle Lösung, da "Auflösungen" in Monorepo (Garne-Arbeitsbereiche) nicht funktionieren.

Und ich erwarte sowieso nicht, dass es die Lösung ist. Meiner Meinung nach sollte das @types- Paket nach der Installation "einfach funktionieren"

Könnte die Lösung für diese ganze Tortur darin bestehen, sie als Peer-Abhängigkeit hinzuzufügen? Sicher ist es nicht narrensicher, aber es ist der einzige Weg, um sicherzustellen, dass Typoskript die erforderliche Abhängigkeit findet

Holen Sie sich Outlook für Android https://aka.ms/ghei36

Von: Maurice [email protected]
Gesendet: Montag, 29. April 2019 12:30:06
An: Definitiv typisiert/Definitiv typisiert
CC: wolfy1339; Erwähnen
Betreff: Re: [DefinitelyTyped/DefinitelyTyped] [@types/react-redux] 'hoist-non-react-statics' hat keinen exportierten Member 'NonReactStatics' (#33690)

Und ich erwarte sowieso nicht, dass es die Lösung ist. Meiner Meinung nach sollte das @types https://github.com/types-Paket nach der Installation "einfach funktionieren"

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail, zeigen Sie sie auf GitHub https://github.com/DefinitelyTyped/DefinitelyTyped/issues/33690#issuecomment-487649204 an oder schalten Sie den Thread stumm https://github.com/notifications/unsubscribe-auth/ABDB6FL2OUVTTX754VHATFLPS4PA5MRCNFQSM4G .

Ich habe viele Dinge ausprobiert, aber das Downgrade auf @types/react-redux 7.0.1 ist im Moment immer noch die einzige Lösung, die funktioniert.

Das gleiche für mich ! Aber ich hoffe, dass eines Tages eine echte Lösung kommt (diese veraltete Abhängigkeit zu behalten ist seltsam!).

Ich denke, wir müssen dasselbe wie #34406 in den React-Redux-Typisierungen tun und nur eine direkte Abhängigkeit von hoist-non-react-statics hinzufügen, da NPM & Yarn nicht unbedingt die "richtige" Version von hoist-non-react-statics im Verzeichnis über @types/react-redux (was dazu führt, dass TS das in v2.5 eingebaute index.d.ts greift, falls es dort ist)

Dies ist eine wirklich knorrige Lösung (und könnte theoretisch abgeschwächt werden, wenn TypeScript es uns ermöglichen würde, @types/hoist-non-react-statics/index.d.ts direkt zu importieren, aber ich sehe keine vernünftigen Alternativen (und im Grunde alle anderen, die auf @types/hoist-non-react-statics angewiesen sind) muss das gleiche tun)

Ich denke, wir müssen dasselbe wie #34406 in den React-Redux-Typisierungen tun und nur eine direkte Abhängigkeit von hoist-non-react-statics hinzufügen, da NPM & Yarn nicht unbedingt die "richtige" Version von hoist-non-react-statics im Verzeichnis über @types/react-redux (was dazu führt, dass TS das in v2.5 eingebaute index.d.ts greift, falls es dort ist)

Dies ist eine wirklich knorrige Lösung (und könnte theoretisch abgeschwächt werden, wenn TypeScript es uns ermöglichen würde, @types/hoist-non-react-statics/index.d.ts direkt zu importieren, aber ich sehe keine vernünftigen Alternativen (und im Grunde alle anderen, die auf @types/hoist-non-react-statics angewiesen sind) muss das gleiche tun)

Wie sieht es mit dem Import aus '../hoist-non-react-statics' aus?
Soweit ich sehe, wird das Paket '@types/hoist-non-react-statics' automatisch installiert, wenn '@types/react-redux' installiert wird, es sollte also keine Gefahr bestehen, dass es fehlt.
Ich habe 2 Dateien angehängt, um eine Lösung zu zeigen, die für mich funktioniert.

Hebezeug-non-react-statics_index.d.txt
reagieren-redux_index.d.txt

Angesichts der Funktionsweise von npm können wir nicht garantieren, dass sich die Eingaben von hoist-non-react-statics in einem Geschwisterverzeichnis von react-redux . Je nachdem, welche anderen Abhängigkeiten der Benutzer installiert hat, kann es sich um ein Großelternteil oder ein Kind handeln.

Das ist bei mir noch kaputt. Mein export default connect()(MyComponent) erhält den Typ any . Zurück zu 7.0.1 behebt diesen Teil... Dies scheint eine Änderung in 7.0.2 .

Passiert immer noch mit 7.1.0 und ein Downgrade auf 7.0.1 ist für uns keine Option, weil wir TS 3.5.2 brauchen (mit TS 3.4.5 , 7.0.1 funktioniert) und das wirft den folgenden Fehler mit 7.0.1 :

node_modules/@types/react-redux/index.d.ts:109:84 - error TS2344: Type 'GetProps<C>' does not satisfy the constraint 'Shared<TInjectedProps, GetProps<C>>'.
  Type 'unknown' is not assignable to type 'Shared<TInjectedProps, GetProps<C>>'.

Also, irgendwelche ... Problemumgehungen? Ich bin kein Experte auf dem Gebiet, daher kann ich nicht verstehen, was ich damit machen soll.

@tsakalidiskostas

Nun, wir haben uns entschieden, eine modifizierte Version der react-redux Typen in unser Repository zu übertragen. (Nachdem Sie sich gegen die Verwendung von Patch-Paketen entschieden haben . Dies kann eine gute vorübergehende Lösung sein, wenn Sie die erforderliche Garnumgehung nicht stören.)

Wobei wir einfach die folgende Zeile ändern:

> = ComponentClass<JSX.LibraryManagedAttributes<C, P>> & hoistNonReactStatics.NonReactStatics<C> & {

zu:

> = ComponentClass<JSX.LibraryManagedAttributes<C, P>> & {

Da wir keine Statik verwenden, schadet es uns nicht, aber das ist natürlich nicht für jeden eine akzeptable Lösung.

Cool! Ich bin mit dem Vorschlag von @alessioprestileo zum Wechseln

import hoistNonReactStatics = require('hoist-non-react-statics');

zum

import { NonReactStatics } from '../hoist-non-react-statics';

und ändere den Anruf zu

> = ComponentClass<JSX.LibraryManagedAttributes<C, P>> & NonReactStatics<C> & {

und es hat auch bei mir funktioniert, wollte eigentlich nur aktualisieren, als ich deine Antwort sah: D

Würden Sie also eine neue Version in npm mit Fixes veröffentlichen? :)

Können wir einfach die Betreuer von Hoist-non-react-statics dazu bringen, die Eingaben wieder in ihr Repo zu überprüfen?

Also .. passiert das oder sollte ich mit einem Gabelwechsel daran weitermachen?

Hi. Wir haben auch auf die neueste 7.1.1 von @types/react-redux Version mit react-redux aktualisiert: 7.1.0 und wir sehen diesen Fehler mit npm. Ich bin verwirrt, da alle diesbezüglichen Tickets geschlossen sind.
Ein Downgrade auf 7.0.1 behebt dieses Problem, verursacht jedoch ein neues Problem, wenn wir die neueste Typescript-Version 3.5.x :

/.../node_modules/@types/react-redux/index.d.ts(109,84): error TS2344: Type 'GetProps<C>' does not satisfy the constraint 'Shared<TInjectedProps, GetProps<C>>'.
  Type 'unknown' is not assignable to type 'Shared<TInjectedProps, GetProps<C>>'.
    Type 'Matching<TInjectedProps, GetProps<C>>' is not assignable to type 'Shared<TInjectedProps, GetProps<C>>'.
      Type 'P extends keyof TInjectedProps ? TInjectedProps[P] extends GetProps<C>[P] ? GetProps<C>[P] : TInjectedProps[P] : GetProps<C>[P]' is not assignable to type 'TInjectedProps[P] extends GetProps<C>[P] ? GetProps<C>[P] : never'.

was es zu einem traurigen Workaround macht.

Die neueste Version (dh 7.1.1 ) von @types/react-redux verwendet Shared<TInjectedProps, GetProps<C>> als Einschränkung (genau wegen dieses Fixes in TS, der darauf hinwies, dass die Einschränkung falsch war) - Sie haben eine andere Bibliothek, die ein verschachteltes Include einer älteren Version der react-redux Typen erzwingt, denke ich.

Also ich habe den Workaround. Es heißt "Patchpaket".

Wenn Sie das Patch-Paket noch nie verwendet haben, ist es eigentlich ganz einfach! Sie fügen es einfach zu Ihrer Konfiguration hinzu, npm installiert es, dann drücken Sie einfach einen Patch-Paketbefehl für das geänderte Modul, das Sie repariert haben und das funktioniert und voila. Jetzt haben Sie ein paar Module, die sich unter einem Patch-Paket befinden, das nur die geänderten Dateien des Moduls enthält, das Sie repariert haben, nichts zu ausgefallen oder zu groß usw. Der Fehler ist behoben, die Abhängigkeit geht nicht verloren, also wenn / wenn sie behoben werden Sie können einfach ein oder zwei Dateien löschen und alles ist in Ordnung

Ich kann bestätigen, dass die Installation von hoist-non-react-statics diesen Fehler für react-redux 7.1.0 und @types/react-redux 7.1.1 behebt. Ich verwende auch Typescript 3.4.3.

Ich weiß jedoch nicht, warum dieses Thema geschlossen ist. Gibt es eine vernünftigere Lösung, ohne das Paket patchen oder den Modulauflösungsbaum überschreiben zu müssen?

Ich habe das gleiche Problem wie @jalMogo

Beobachte dieses Problem immer noch.

@jalMogo Soweit ich das verstanden habe, ist dies kein Problem mit Redux, sondern mit Hoist-Non-React-Statik und deshalb wird das Problem hier geschlossen. Es gibt mehrere Problemumgehungen in dem Thread, aber es wäre besser, wenn jemand, der erfahren genug ist, den Hebezeugen eine Lösung geben würde.

Ich bin nicht der Meinung, dass es sich um ein Problem mit der Hubwerks-Nicht-Reaktions-Statik handelt. Es ist ein Problem mit der Beschreibung von Redux, da es am Ende die ältere und falsche Version von hoist-non-react-statics betrachtet, wenn es im node_modules-Baum existiert, was es tut, wenn andere Dinge wie der Router installiert sind . Die Abhängigkeit muss richtig beschrieben werden und die neue Version muss näher im Baum node_modules installiert werden.

Dies ist immer noch ein Thema.

+1

Ich erhalte dieses Problem immer noch und der Lint sagt, dass ein Fehler im Code vorliegt. Arbeitet noch jemand daran oder gilt es als geschlossen? Ich habe alle aktuellen Versionen installiert und bekomme immer noch:

Namespace '"/home/myhome/Projects/node_modules/hoist-non-react-statics/index"' hat keinen exportierten Member 'NonReactStatics'.ts(2694)

Dies ist definitiv ein Problem von ihrer Seite. Problemumgehung: @types/hoist-non-react-statics sollte als Abhängigkeit in IHREM Projekt aufgeführt sein, damit es funktioniert

Aber ich habe das und habe immer noch das Problem:
"Abhängigkeiten": {
...
"@types/hoist-non-react-statics": "^3.3.1",

ist in meinem package.json

Mein Fehler. Du brauchst hoist-non-react-statics

Von: Robert Rehammar [email protected]
Gesendet: Sonntag, 20. Oktober 2019 01:50:51
An: DefinitelyTyped/DefinitelyTyped [email protected]
Cc: wolfy1339 [email protected] ; Erwähnen Sie Erwä[email protected]
Betreff: Re: [DefinitelyTyped/DefinitelyTyped] [@types/react-redux] 'hoist-non-react-statics' hat keinen exportierten Member 'NonReactStatics' (#33690)

Aber ich habe das und habe immer noch das Problem:
"Abhängigkeiten": {
...
"@types/hoist-non-react-statics": "^3.3.1",

ist in meinem package.json

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie auf diese E - Mail direkt, sehen sie auf GitHub https://github.com/DefinitelyTyped/DefinitelyTyped/issues/33690?email_source=notifications&email_token=ABDB6FORFBHI575QMINWIQ3QPPWTXA5CNFSM4G4MRVM2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBYC7IY#issuecomment-544223139 oder abmelden https://github.com/notifications/unsubscribe- auth/ABDB6FLBLRAIO2PIIGMMJY3QPPWTXANCNFSM4G4MRVMQ .

Ich habe "hoist-non-react-statics": "^3.3.0" in meinen Abhängigkeiten und "@types/hoist-non-react-statics": "^3.3.1" in meinen devDependencies und ich habe das Problem auch immer noch. Ich habe bestätigt, dass auch keine anderen Bibliotheken ältere Versionen davon einziehen.

Ich habe es auch versucht, ohne "@types/hoist-non-react-statics" explizit zu installieren (denn nach meinem Verständnis sollte das Hauptpaket bereits Eingaben enthalten), aber mit dem gleichen Ergebnis.

Jeder, der mit diesem Problem konfrontiert ist, sollte eine lauffähige Reproduktion bereitstellen, ansonsten können wir keine Hilfe anbieten.

Es tut mir leid, das Projekt, das ich erlebe, ist nicht Open Source und ich habe nicht die Zeit, ein separates Projekt zu erstellen, um es zu präsentieren. Was mir jedoch aufgefallen ist, ist, dass das Projekt keine Probleme hatte, bis ich allowJs: true im tsconfig.json aktivierte. Ohne diese Einstellung funktionierte noch alles einwandfrei. Ich hoffe es hilft.

Das Hinzufügen der 'Hebezeug-Nicht-Reakt-Statik' scheint dies hier behoben zu haben.

repro installiert nur @types/react-redux und importiert dann alles in React-Redux in eine tsx-Datei.

Eine Möglichkeit, dieses Problem zu beheben, besteht darin, "skipLibCheck": true in tsconfig.json hinzuzufügen. Es ist nicht die beste Lösung, aber als Workaround kann es verwendet werden.

Ich denke, das passiert, weil Typoskript die Dinge in dieser Reihenfolge auflöst:

1. package/package.json[types]
2. @types/package
3. package (alles außer dem Feld types )

Warum es das tut, ist mir ein Rätsel, aber es ist hier dokumentiert: https://www.typescriptlang.org/docs/handbook/module-resolution.html#how -typescript-resolves-modules

Wenn Sie also beispielsweise die folgende Verzeichnisstruktur haben:

node_modules/
  @types/
    hoist-non-react-statics/ (3.3.0)
    react-redux/
      node_modules/
        hoist-non-react-statics/ (3.3.0)

  hoist-non-react-statics/
    package.json (2.0, which has a types field!!!)
    index.d.ts

Dann macht Typoskript folgendes:

1. Fehler beim Abrufen von Typen von node_modules/@types/react-redux/node_modules/hoist-non-react-statics da die aktuelle Version keine Typen enthält
2. gelingt es, Typen aus node_modules/hoist-non-react-statics (der alten Version) zu finden, weil sein package.json ein types Feld hat

Daher können Sie, wie andere bereits erwähnt haben, das Problem beheben, indem Sie in Ihrem Projekt eine Abhängigkeit zu den neuesten hoist-non-react-statics hinzufügen, da dies kein types Feld in package.json hat lässt Schritt 2 fehlschlagen.

Ironischerweise können Sie es auch beheben, indem Sie Ihrem Projekt eine Abhängigkeit von einem älteren hoist-non-react-statics hinzufügen, zB 3.0.0. Dies funktioniert, weil es die Installation der korrekten Version (3.3.0) in node_modules/@types/react-redux/node_modules/types/hoist-non-react-statics erzwingt, wo es zuvor gelöst wurde :confounded:

Also ich habe zwei Fragen:

1. Warum behandelt Typoskript das Feld types speziell auf diese Weise, und es kommt vor oder nach @types Paketen, je nachdem, ob das Feld types verwendet wird oder nicht?
2. Wenn hoist-non-react-statics einmal Typen eingebaut hatte, warum wurden sie dann hierher überführt? Dies wäre kein Problem, wenn die Typen in das Paket integriert wären. Ich kann nicht sehen, wie Garn / NPM mit separaten Paketen für Code und Typen richtig umgehen kann, da sie nicht wissen, wie die beiden verbunden sind.

Dieses Problem scheint mit den neuesten Paketversionen wieder aufgetaucht zu sein, dh:

[email protected]
@types/[email protected]

Ich konnte dies beheben, indem ich die folgenden Pakete manuell in mein package.json :

[email protected]
@types/[email protected]

Da die hoist-non-react-statics Pakete nach meinen ursprünglichen npm install Paketen Duplikate dieser Pakete in meinem node_modules Ordner waren. Das Laufen von npm dedupe geklärt.

Hoffe, das hilft allen anderen, die mitkommen!

Ich hatte dieses Problem auch - Lob sei an @DannyDelotts Lösung!

Ich hatte dieses Problem auch - Lob sei an @DannyDelotts Lösung!

Die derzeit schnellste Lösung, ohne Ihr package.json mit Abhängigkeiten zu belasten, die Sie nicht direkt benötigen, ist das Entfernen von @types/react-redux

npm remove @types/react-redux

Sobald wir sehen, dass dieses Problem behoben wurde, können wir es zurückstellen

Das Problem tritt immer noch auf und die einzige Möglichkeit, dies zu beheben, besteht darin, die genannten Abhängigkeiten zu Ihrem Projekt hinzuzufügen. Dies ist jedoch nicht ideal, also werden wir hoffentlich bald eine Lösung finden!

Bemerke dieses Problem immer noch.

Für jeden, der bereit ist, sich weiterzuentwickeln, während ein stabiler Fix live ist, können Sie den folgenden typedef verwenden:

// [your-src-folder]/types/hoist-non-react-statics.d.ts

declare module 'hoist-non-react-statics' {
  type NonReactStatics<T> = any;
  export { NonReactStatics }
}

Dies ist nicht die ideale Lösung, aber zumindest nützlich, um Build-Fehler mit TS zu vermeiden