Definitelytyped: [@types/react-redux] 'hoist-non-react-statics' n'a pas de membre exporté 'NonReactStatics'

Aïe. J'ai introduit une dépendance sur @types/hoist-non-react-statics dans ce changement, mais je ne l'ai pas ajouté en tant que dépendance. Ce problème est que je ne sais pas où le déclarer en tant que dépendance, car les types ne dépendent que des types.

@JounQin , pouvez-vous m'aider à comprendre comment résoudre ce problème. Avons-nous besoin d'ajouter un ///<reference ou d'ajouter quelque chose au package.json ?

Comme solution de contournement temporaire, vous pouvez npm install --dev @types/hoist-non-react-statics à votre projet.

Je peux me tromper mais je pense que le problème est peut-être plus simple,

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

devrait être

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

la rétrogradation vers @types/react-redux 7.0.1 est une solution rapide jusqu'à ce que cela soit corrigé.

J'ai eu ce problème aujourd'hui aussi. La mise à niveau vers 7.0.1 a aidé

Pareil ici.

Aïe. J'ai introduit une dépendance sur @types/hoist-non-react-statics dans ce changement, mais je ne l'ai pas ajouté en tant que dépendance

DefinitelyTyped a automatiquement ajouté @types/hoist-non-react-statics tant que dépendance à @types/react-redux , mais (apparemment) cela n'était pas suffisant pour que vos saisies fonctionnent.

Comme solution de contournement temporaire, vous pouvez npm install --dev @types/hoist-non-react-statics à votre projet.

Non, cela ne fonctionnera pas car cette dépendance est déjà ajoutée automatiquement par DefinitelyTyped, mais ce n'est pas suffisant pour que TS traite correctement vos frappes.

Je suppose que le problème est que TS n'est pas au courant de l'existence du module hoist-non-react-statics , car le package hoist-react-statics lui-même n'est pas présent dans node_modules (c'est dommage que TS ne puisse pas dériver l'existence du module de @types/hoist-non-react-statics package, bien qu'il puisse y avoir une raison valable pour un tel comportement, par exemple la compatibilité). Cette hypothèse est confirmée par le fait que l' installation manuelle de hoist-non-react-statics fait que vos saisies fonctionnent correctement .

Donc, @jamesreggio, je suppose que vous devez ajouter le package hoist-non-react-statics en tant que dépendance au package.json de @types/react-redux afin de résoudre ce problème.

@surgeboris mis à jour vers 7.0.3 et ajouté [email protected] et @types/[email protected] , correction d'un problème

Le correctif ne fonctionne pas vraiment pour moi. Peut-être que je fais quelque chose de mal. Utilisation du fil 1.13

Ok tout le monde, merci pour votre patience.

J'ai trouvé un correctif et ouvert un PR : #33919.

Apparemment, si vous utilisez l'exportation de définition de type de type nœud (avec export = ), la bonne façon d'importer est d'utiliser import [name] = require([package name]) . Je ne connais pas bien les nuances de ces schémas d'import/export, et je suis seulement vaguement plus confiant de le comprendre maintenant 😆

Espérons que les mainteneurs de DefinitielyTyped puissent fusionner et publier cela dès que possible. Désolé encore pour la régression.

Malheureusement, même avec 7.0.4 qui a été récemment publié, cela n'a pas résolu le problème pour moi

Il semble que la dépendance explicite sur @types/hoist-non-react-statics soit toujours manquante.

en fait, non - un nouveau npm i @types/react-redux installé @types/hoist-non-react-statics . Je ne vois aucun problème ?

Oui, la dépendance est définitivement répertoriée dans son package.json :

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

si vous rencontrez toujours des problèmes, vous devez vérifier que les bonnes versions de tout ont été installées.

(Plus précisément, la dépendance est répertoriée sous la forme * , vous pouvez donc avoir une ancienne version de @types/hoist-non-react-statics qui manque peut-être du type que npm compte comme satisfaisant la dépendance ?)

Le problème est donc quelque peu nuancé.

Le package hoist-non-react-statics incluait ses propres typages hyper-basiques de v2.2.0 jusqu'à v3.0.0 , et si la version de hoist-non-react-statics qui se résout dans votre projet root dans ce range, vous rencontrerez cette erreur car les typages package-local ont la priorité sur @types/hoist-non-react-statics .

Il existe deux solutions de contournement immédiates :

1. Ajoutez hoist-non-react-statics@^3.3.0 à votre projet en tant que dépendance.
2. Si vous utilisez du fil, ajoutez un remplacement de résolution à votre package.json tant que tel :
   "resolutions": { "hoist-non-react-statics": "^3.3.0" }

Ni l'un ni l'autre n'est optimal, car la plupart des développeurs ne sont (à juste titre) pas au courant de l'existence de hoist-non-react-statics en premier lieu.

Je ne sais pas vraiment quelle serait l'approche optimale ici, mais je soupçonne que si nous pouvions répertorier une spécification de version spécifique pour @types/hoist-non-react-statics intérieur du package.json pour @types/react-redux , nous pourrait atténuer l'impact.

@weswigham — savez-vous s'il est possible de remplacer la dépendance générée automatiquement par * par une dépendance sur @types/hoist-non-react-statics avec >=3.3.0 ?

@weswigham — savez-vous s'il est possible de remplacer la dépendance générée automatiquement par * par une dépendance sur @types/hoist-non-react-statics avec >=3.3.0 ?

Si vous l'ajoutez explicitement dans le package.json cela pourrait fonctionner ? AFAIK, vous ne pouvez pas coder en dur les versions pour les dépendances implicites ou basées sur le mappage de chemin, mais je peux me tromper.

@sandersn en sait-il plus ?

Je viens d'ouvrir un PR qui inclut une version spécifique de @types/hoist-non-react-statics dans le package.json . Espérons que cela fonctionne? Cela ne pouvait certainement pas faire de mal.

@weswigham , cela vous dérange-t-il de revoir et de donner votre approbation ?

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

Je ne sais pas si c'est la bonne solution. J'ai ajouté une dépendance directe sur hoist-non-react-statics@latest et cela a résolu tous les problèmes.

Ugh, @weswigham + @sandersn — je ne sais pas quoi faire. La construction de Travis a échoué car j'ai ajouté une spécification de version spécifique pour @types/hoist-non-react-statics . Voir l'erreur ici .

Il est vrai que mon changement vers @types/react-redux _requiert_ un minimum de 3.3.0 de @types/hoist-non-react-statics , donc je pense que je devrais pouvoir exprimer cette contrainte. Pouvez-vous m'aider à comprendre comment faire cela? (Devrais-je faire comme le message d'erreur l'indique et l'ajouter à dependenciesWhitelist.txt dans types-publisher ? Cela semble être un trop gros marteau.)

Ce n'est pas un trop gros marteau - votre problème est à peu près exactement ce que le message de journal décrit (sauf que nous sommes également revenus une fois de plus au paquet sous-jacent et non aux types d'expédition, toute la saga).

Cool, j'ai un PR prêt à fusionner sur types-publisher : https://github.com/Microsoft/types-publisher/pull/595

@weswigham - pouvez-vous l'atterrir ?

Il est publié à 15h06 PDT (40 minutes avant ce commentaire environ).

D'accord les gars, essayez @types/[email protected] et faites-moi savoir si vous êtes toujours en panne.

Toujours le même problème avec @types/[email protected] . La seule solution qui a fonctionné pour moi est d'exiger manuellement hoist-non-react-statics dans mon projet

Secondé, toujours cassé dans @types/ [email protected].

@jamesreggio @weswigham Je ne sais pas si vous avez vu les commentaires mais je vous

Oui, merci, j'avais. J'enseignais React cet après-midi à Cisco lorsque cela a mordu la classe. Après une vérification rapide et j'ai trouvé ce fil, je les ai ramenés à 7.0.1 et cela a fonctionné correctement. Mais, j'ai une légère bizarrerie. Si j'ajoute des statiques non réactives, cela fonctionne, comme décrit ci-dessus. Si je désinstalle hoist-non-react-statics, cela continue de fonctionner. Alors peut-être qu'il y a une vraie dépendance qui y est détectée, mais qui persiste même si vous supprimez ce paquet. Si j'efface node_modules et package-lock.json et réinstalle sans palan, c'est à nouveau cassé. Je dois sortir d'ici maintenant, donc je ne peux plus passer de temps dessus pour essayer de creuser plus profondément. Quelqu'un d'autre pourrait le trouver plus rapide de toute façon étant plus en phase avec le package.

Je vais creuser à nouveau demain, mais honnêtement, j'ai besoin d'aide
d'un expert. Les subtilités du système de module TS me déroutent. Je ressens
comme si j'avais tout fait correctement ici...

Ceux d'entre vous qui ont le problème peuvent-ils coller un aperçu de votre
package-lock.json ou fil.lock ? J'ai l'impression que cela peut être un problème lié
au fait inhabituel que la statique de levage non réactive inclue ses propres typages
pendant une courte période dans le passé.

Le jeu. 21 mars 2019 à 20h03, Joel Mussman [email protected] a écrit :

Oui, merci, j'avais. J'enseignais React cet après-midi à Cisco quand ce
peu la classe. Après une vérification rapide et j'ai trouvé ce fil, je les ai récupérés
jusqu'à 7.0.1 et cela a fonctionné correctement. Mais, j'ai une légère bizarrerie. Si j'ajoute
hoist-non-react-statics, cela fonctionne, comme décrit ci-dessus. Si je désinstalle
Hoist-non-react-statics, il continue de fonctionner. Alors peut-être qu'il y a un vrai
dépendance qui est récupérée là-bas, mais reste même si vous supprimez
ce paquet. Si j'efface node_modules et package-lock.json et
réinstaller sans palan, c'est à nouveau cassé. Je dois sortir d'ici maintenant,
donc je ne peux plus passer de temps dessus en ce moment à essayer de creuser plus profondément.
Quelqu'un d'autre pourrait le trouver plus rapide de toute façon étant plus en phase avec le
emballer.

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/DefinitelyTyped/DefinitelyTyped/issues/33690#issuecomment-475477877 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AAyLva1P2ZGe86669tG7yu7fe1yMWWf-ks5vZEgHgaJpZM4bjI1Z
.

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

Bonjour James,

OK, je comprends ce qui ne va pas dans mon projet de classe. Je ne sais pas encore comment y remédier. Mais, je vais publier ce que je sais, et peut-être que quelqu'un chez Definitely Typed pourra peut-être vous aider.

react-router est installé avant react-redux par le laboratoire précédent. La version actuelle de react-router (jusqu'à il y a 4 jours) était la 4.3.1 et dépend de [email protected]. Ainsi, selon les règles, puisque personne d'autre n'avait de dépendance à hoist-non-react-statics, le package était installé au niveau supérieur de node_modules. Maintenant, [email protected] est installé. Cela dépend de [email protected]. Mais, puisque 2.2.5 est déjà au niveau supérieur, il met 3.3.0 dans le dossier node_modules SOUS React-redux. Il semble donc que la dépendance dans @types/react-redux de @types/ [email protected] ne la trouve pas car elle n'est pas au niveau supérieur. Ces règles dans lesquelles je n'ai pas encore creusé, mais quelqu'un d'autre pourra peut-être les cerner tout de suite.

D'autres problèmes de personnes décrits précédemment peuvent être très similaires à ce scénario.

Question connexe : comment sommes-nous censés savoir quelle version de @types/react-redux correspond à quelle version de react-redux ? Comme les chiffres ne correspondent pas, je suis perdu là.

J'ai fait un PR pour résoudre ce problème #34090

Ce problème ne devrait-il pas être rouvert car le problème sous-jacent n'est pas encore résolu avec la version 7.0.5 ?
(sans ajouter @types/hoist-non-react-statics + hoist-non-react-statics aux devDependencies)

100% d'accord que cela ne devrait pas être fermé, toujours cassé à moins que vous ne l'ajoutiez manuellement à devDependancies

J'ai déposé le correctif approprié que les gens ici semblent ignorer depuis le début : #34406

Alors maintenant que le PR est fusionné, les types react-redux doivent mettre à jour la dépendance sur hoist-non-react-statics ?

Je pense que oui. Mais je pense que vous pouvez supprimer la dépendance (la désinstaller) et la rajouter

De : Maurice [email protected]
Envoyé : jeudi 4 avril 2019 15:53:32
À : Tapé définitivement/Type définitivement tapé
Cc : wolfy1339 ; Manuel
Objet : Re : [DefinitelyTyped/DefinitelyTyped] [@types/react-redux] 'hoist-non-react-statics' n'a pas de membre exporté 'NonReactStatics' (#33690)

Alors maintenant que le PR est fusionné, les types react-redux doivent mettre à jour la dépendance sur hoist-non-react-statics ?

-
Vous recevez ceci parce que vous êtes abonné à ce fil.
Répondez directement à cet e-mail, affichez-le sur GitHub https://github.com/DefinitelyTyped/DefinitelyTyped/issues/33690#issuecomment-480039685 , ou coupez le fil de discussion https://github.com/notifications/unsubscribe-auth/AEYfFbvvu7_1ZrU42jUUUxkZL4ks3uwg5

Vous voulez dire les typages de réaction-redux ? Je vais essayer ça.

@wolfy1339 https://github.com/DefinitelyTyped/DefinitelyTyped/pull/34406 n'a pas semblé résoudre le problème pour moi. Je pense que c'est parce que hoist-non-react-statics sera installé dans @types/hoist-non-react-statics ( node_modules/@types/hoist-non-react-statics/node_modules/hoist-non-react-statics ), donc TS utilise toujours les types de ma version racine ( node_modules/hoist-non-react-statics ).

À ce stade, cela valait la peine d'essayer. Quelqu'un d'autre a une idée?

@weswigham Pouvez-vous rouvrir ce problème ?

J'ai eu un problème similaire - l'utilisation de fil au lieu de npm pour installer des dépendances a résolu mon problème. Publier en note parce que vous pouvez peut-être essayer comme solution de contournement.

@alan-mroczek Nous utilisons du fil, donc non, cela n'aide pas. Il doit y avoir autre chose en jeu ici. (verrouiller le fichier ?)

Je ne sais pas si je comprends le problème exact, mais la solution qui a fonctionné pour moi avec le fil était d'ajouter un champ de résolutions à package.json.

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

Ce problème est toujours actif pour "@types/react-redux": "7.0.8", et la définition de "résolutions" n'est pas une solution universelle car les "résolutions" ne fonctionnent pas en monorepo (espaces de travail de fils)

Et je ne m'attends pas à ce que ce soit la solution de toute façon. À mon avis, le package @types après son installation devrait "juste fonctionner"

La solution à toute cette épreuve pourrait-elle être de l'ajouter en tant que dépendance aux pairs ? Bien sûr, ce n'est pas infaillible, mais c'est le seul moyen de garantir que le script dactylographié trouve la dépendance requise

Obtenez Outlook pour Android https://aka.ms/ghei36

De : Maurice [email protected]
Envoyé : lundi 29 avril 2019 12:30:06
À : Tapé définitivement/Type définitivement tapé
Cc : wolfy1339 ; Mention
Objet : Re : [DefinitelyTyped/DefinitelyTyped] [@types/react-redux] 'hoist-non-react-statics' n'a pas de membre exporté 'NonReactStatics' (#33690)

Et je ne m'attends pas à ce que ce soit la solution de toute façon. À mon avis, le package @types https://github.com/types après son installation devrait "juste fonctionner"

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub https://github.com/DefinitelyTyped/DefinitelyTyped/issues/33690#issuecomment-487649204 , ou coupez le fil de discussion https://github.com/notifications/unsubscribe-auth/ABDB6FL2OUVTTX754VHATFLPS4PA45MRANCNFSM4G .

J'ai essayé beaucoup de choses, la rétrogradation vers @types/react-redux 7.0.1 est toujours le seul correctif qui fonctionne pour le moment.

La même chose pour moi ! Mais j'espère qu'un vrai correctif viendra un jour (c'est bizarre de garder cette dépendance obsolète !).

Je pense que nous devons faire la même chose que #34406 dans les typages react-redux, et juste ajouter une dépendance directe sur hoist-non-react-statics , car NPM & Yarn ne vont pas nécessairement mettre la version "correcte" de hoist-non-react-statics dans le répertoire au-dessus de @types/react-redux (ce qui amènera TS à récupérer le index.d.ts intégré de la v2.5 s'il est là)

C'est une solution vraiment compliquée (et pourrait théoriquement être atténuée si TypeScript nous permettait d'importer @types/hoist-non-react-statics/index.d.ts directement, mais je ne vois pas d'alternative raisonnable (et fondamentalement toute autre personne qui dépend de @types/hoist-non-react-statics va devoir faire la même chose)

Je pense que nous devons faire la même chose que #34406 dans les typages react-redux, et juste ajouter une dépendance directe sur hoist-non-react-statics , car NPM & Yarn ne vont pas nécessairement mettre la version "correcte" de hoist-non-react-statics dans le répertoire au-dessus de @types/react-redux (ce qui amènera TS à récupérer le index.d.ts intégré de la v2.5 s'il est là)

C'est une solution vraiment compliquée (et pourrait théoriquement être atténuée si TypeScript nous permettait d'importer @types/hoist-non-react-statics/index.d.ts directement, mais je ne vois pas d'alternative raisonnable (et fondamentalement toute autre personne qui dépend de @types/hoist-non-react-statics va devoir faire la même chose)

Qu'en est-il de l'importation à partir de « ../hoist-non-react-statics » ?
Pour autant que je sache, le package '@types/hoist-non-react-statics' est automatiquement installé lorsque '@types/react-redux' est installé, il ne devrait donc y avoir aucun risque qu'il manque.
J'ai joint 2 fichiers pour montrer une solution qui fonctionne pour moi.

hoist-non-react-statics_index.d.txt
réagir-redux_index.d.txt

Étant donné la façon dont fonctionne npm, nous ne pouvons pas garantir que les saisies hoist-non-react-statics seront dans un répertoire frère de react-redux . Selon les autres dépendances que l'utilisateur a installées, il peut s'agir d'un grand-parent ou d'un enfant.

C'est encore cassé pour moi. Mon export default connect()(MyComponent) reçoit un type any . Revenir à 7.0.1 corrige cette partie... Cela semble être un changement dans 7.0.2 .

Cela arrive toujours avec 7.1.0 et la rétrogradation à 7.0.1 n'est pas une option pour nous car nous avons besoin de TS 3.5.2 (avec TS 3.4.5 , 7.0.1 fonctionne) et cela renvoie l'erreur suivante avec 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>>'.

Alors, des solutions de contournement ? Je ne suis pas un expert en la matière, donc je ne comprends pas ce que je dois faire avec ça.

@tsakalidiskostas

Eh bien, nous avons décidé de valider une version modifiée des types react-redux dans notre dépôt. (Après avoir décidé de ne pas utiliser patch-package . Ce qui peut être une bonne solution temporaire si la solution de contournement de fil nécessaire ne vous dérange pas.)

Où on change simplement la ligne suivante :

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

à:

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

Comme nous n'utilisons pas de statique, cela ne nous fait pas de mal mais cela peut bien sûr ne pas être une solution acceptable pour tout le monde.

Frais! Je suis allé avec la suggestion de @alessioprestileo de changer

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

pour

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

et changer l'appel en

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

et cela a fonctionné pour moi aussi, je me dirigeais juste vers la mise à jour quand j'ai vu votre réponse :D

Alors publieriez-vous une nouvelle version dans npm avec des correctifs ? :)

Pouvons-nous simplement demander aux mainteneurs de hoist-non-react-statics de vérifier les saisies dans leur référentiel ?

Alors… est-ce que cela se produit ou dois-je procéder à un changement de fourchette à ce sujet ?

Salut. Nous avons également mis à jour la dernière version 7.1.1 de @types/react-redux avec react-redux : 7.1.0 et nous voyons cette erreur avec npm. Je suis confus car tous les billets faisant référence à cela sont fermés.
Une mise à niveau vers 7.0.1 résout ce problème mais provoque un nouveau problème si nous utilisons la dernière version Typescript 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'.

ce qui en fait une solution de contournement un peu triste.

La dernière version (c'est-à-dire 7.1.1 ) de @types/react-redux n'utilise pas Shared<TInjectedProps, GetProps<C>> comme contrainte (précisément à cause de ce correctif dans TS qui indiquait que la contrainte était incorrecte) - vous avez une autre bibliothèque qui force une inclusion imbriquée d'une ancienne version des types react-redux , je pense.

Donc, j'ai la solution de contournement. C'est ce qu'on appelle le "paquet de correctifs".

Si vous n'avez jamais utilisé le package de correctifs auparavant, c'est en fait assez simple ! Vous l'ajoutez simplement à votre configuration, npm l'installez, puis vous appuyez simplement sur une commande de package de correctifs sur le module modifié que vous avez corrigé et qui fonctionne et le tour est joué. Maintenant, vous avez quelques modules qui résident sous le paquet de correctifs qui ne contient que les fichiers modifiés du module que vous répariez, rien de trop sophistiqué ou de trop gros, etc. L'erreur est corrigée, la dépendance n'est pas perdue, donc quand / s'ils corrigent vous pouvez facilement supprimer un ou deux fichiers et tout va bien

Je peux confirmer que l'installation de hoist-non-react-statics résout cette erreur pour react-redux 7.1.0 et @types/react-redux 7.1.1 J'utilise également Typescript 3.4.3.

Je ne sais pas pourquoi ce sujet est fermé, cependant. Existe-t-il une solution plus raisonnable, sans avoir à patcher le package ou à remplacer l'arborescence des résolutions de module ?

J'ai le même problème que @jalMogo

Toujours en train de voir ce problème.

@jalMogo, pour autant que je

Je ne suis pas d'accord pour dire que c'est un problème avec la statique de non-réaction de levage. C'est un problème avec la description de redux, en ce sens qu'il finit par regarder l'ancienne et la mauvaise version de hoist-non-react-statics si elle existe dans l'arborescence node_modules, ce qu'elle fait lorsque d'autres éléments comme le routeur sont installés . La dépendance doit être décrite correctement et la nouvelle version correctement installée plus près de l'arborescence node_modules.

C'est toujours un problème.

+1

J'ai toujours ce problème et la peluche dit qu'il y a une erreur dans le code. Quelqu'un y travaille-t-il encore ou est-il considéré comme fermé ? J'ai toutes les dernières versions installées et j'obtiens toujours :

L'espace de noms '"/home/myhome/Projects/node_modules/hoist-non-react-statics/index"' n'a pas de membre exporté 'NonReactStatics'.ts(2694)

C'est certainement un problème de leur part. Solution : @types/hoist-non-react-statics doit être répertorié comme une dépendance dans VOTRE projet pour qu'il fonctionne

Mais j'ai ça, et j'ai toujours le problème:
"dépendances": {
...
"@types/hoist-non-react-statics": "^3.3.1",

est dans mon package.json

Ma faute. Vous avez besoin de hoist-non-react-statics

De : Robert Rehammar [email protected]
Envoyé : dimanche 20 octobre 2019 01:50:51
À : DefinitelyTyped/DefinitelyTyped [email protected]
Cc : wolfy1339 [email protected] ; Mentionnez [email protected]
Objet : Re : [DefinitelyTyped/DefinitelyTyped] [@types/react-redux] 'hoist-non-react-statics' n'a pas de membre exporté 'NonReactStatics' (#33690)

Mais j'ai ça, et j'ai toujours le problème:
"dépendances": {
...
"@types/hoist-non-react-statics": "^3.3.1",

est dans mon package.json

-
Vous recevez ceci parce que vous avez été mentionné.
Répondre à cet e - mail directement, voir sur GitHub https://github.com/DefinitelyTyped/DefinitelyTyped/issues/33690?email_source=notifications&email_token=ABDB6FORFBHI575QMINWIQ3QPPWTXA5CNFSM4G4MRVM2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBYC7IY#issuecomment-544223139 ou désabonnement https://github.com/notifications/unsubscribe- auth/ABDB6FLBLRAIO2PIIGMMJY3QPPWTXANCNFSM4G4MRVMQ .

J'ai "hoist-non-react-statics": "^3.3.0" dans mes dépendances et "@types/hoist-non-react-statics": "^3.3.1" dans mes devDependencies et j'ai toujours le problème moi-même. J'ai confirmé qu'aucune autre bibliothèque n'utilise d'anciennes versions de celles-ci non plus.

J'ai également essayé sans installer explicitement "@types/hoist-non-react-statics" (car d'après ce que j'ai compris, le package principal devrait déjà avoir des saisies incluses), mais avec le même résultat.

Toute personne confrontée à ce problème doit fournir une reproduction exécutable, sinon nous ne pouvons offrir aucune aide.

Je suis désolé, le projet que je vis n'est pas open-source et je n'ai pas le temps de créer un projet séparé pour le présenter. Ce que j'ai remarqué cependant, c'est que le projet n'a eu aucun problème jusqu'à ce que j'active allowJs: true dans le tsconfig.json . Sans ce paramètre, tout fonctionnait bien. J'espère que ça aide.

l'ajout du 'hoist-non-react-statics' semble l'avoir corrigé ici.

repro installe simplement @types/react-redux, puis importe quoi que ce soit dans react-redux dans un fichier tsx.

Une façon de résoudre ce problème consiste à ajouter "skipLibCheck": true dans tsconfig.json. Ce n'est pas la meilleure solution, mais comme solution de contournement, elle peut être utilisée.

Je pense que cela se produit parce que tapscript résout les choses dans cet ordre :

1. package/package.json[types]
2. @types/package
3. package (tout sauf le champ types )

Pourquoi cela est-il un mystère pour moi, mais c'est documenté ici : https://www.typescriptlang.org/docs/handbook/module-resolution.html#how -typescript-resolves-modules

Ainsi, par exemple, si vous avez la structure de répertoires suivante :

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

Ensuite, typescript effectuera les opérations suivantes :

1. ne parvient pas à obtenir les types de node_modules/@types/react-redux/node_modules/hoist-non-react-statics car la version actuelle n'inclut pas les types
2. réussir à trouver des types à partir de node_modules/hoist-non-react-statics (l'ancienne version) car son package.json a un champ types

Par conséquent, comme d'autres l'ont mentionné, vous pouvez résoudre le problème en ajoutant une dépendance dans votre projet sur le dernier hoist-non-react-statics , car cela n'a pas types champ package.json donc il fait échouer l'étape 2.

Ironiquement, vous pouvez également le corriger en ajoutant une dépendance dans votre projet sur un ancien hoist-non-react-statics , par exemple 3.0.0. Cela fonctionne car cela force l'installation de la version correcte (3.3.0) dans node_modules/@types/react-redux/node_modules/types/hoist-non-react-statics , où elle est résolue plus tôt :confounded:

J'ai donc deux questions :

1. Pourquoi le typescript traite-t-il spécialement le champ types de cette manière, et il vient avant ou après les packages @types selon que le champ types est utilisé ou non ?
2. Si hoist-non-react-statics avaient une fois des types intégrés, pourquoi ont-ils été renégats ici ? Ce ne serait pas un problème si les types étaient intégrés dans package. Je ne vois pas comment wire/NPM peut gérer correctement des packages séparés pour le code et les types, car ils ne savent pas comment les deux sont connectés.

Ce problème semble avoir refait surface avec les dernières versions du package, c'est-à-dire :

[email protected]
@types/[email protected]

J'ai pu résoudre ce problème en incluant manuellement les packages suivants dans mon package.json :

[email protected]
@types/[email protected]

Parce que les packages hoist-non-react-statics après mon npm install initial, il y avait des doublons de ces packages dans mon dossier node_modules . L'exécution de npm dedupe clarifié cela.

J'espère que cela aidera tous ceux qui viendront!

J'ai également eu ce problème - l'éloge de la solution de @DannyDelott !

J'ai également eu ce problème - l'éloge de la solution de @DannyDelott !

La solution la plus rapide pour le moment sans polluer votre package.json avec des dépendances dont vous n'avez pas directement besoin est de supprimer @types/react-redux

npm remove @types/react-redux

Une fois que nous voyons que ce problème a été résolu, nous pouvons le remettre en place

Le problème persiste et le seul moyen de le résoudre est d'ajouter les dépendances mentionnées à votre projet. Ce n'est pas idéal, cependant, alors j'espère que nous aurons bientôt une solution !

Toujours en train de remarquer ce problème.

Pour tous ceux qui souhaitent continuer à développer pendant qu'un correctif stable sera en ligne, vous pouvez utiliser le typedef ci-dessous :

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

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

Ce n'est pas la solution idéale, mais au moins c'est utile pour éviter les erreurs de construction avec TS