Definitelytyped: [@ types / react-redux] 'hoist-non-react-statics' no tiene un miembro exportado 'NonReactStatics'

¡Ay! Introduje una dependencia de @types/hoist-non-react-statics en ese cambio, pero no la agregué como dependencia. Este problema es que no estoy seguro de dónde declararlo como una dependencia, ya que los tipos solo dependen de los tipos.

@JounQin , ¿puedes ayudarme a entender cómo solucionar esto? ¿Necesitamos agregar un ///<reference o agregar algo al package.json ?

Como solución temporal, puede npm install --dev @types/hoist-non-react-statics para su proyecto.

Podría estar equivocado, pero creo que el problema es quizás más simple,

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

debiera ser

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

La degradación a @ types / react-redux 7.0.1 es una solución rápida hasta que se solucione.

Hoy también tengo este problema. La degradación a 7.0.1 ayudó

Aquí igual.

¡Ay! Introduje una dependencia de @types/hoist-non-react-statics en ese cambio, pero no la agregué como dependencia

DefinitelyTyped agregó automáticamente @types/hoist-non-react-statics como dependencia a @types/react-redux , pero (aparentemente) eso no fue suficiente para que tu mecanografía funcionara.

Como solución temporal, puede npm install --dev @types/hoist-non-react-statics para su proyecto.

No, eso no funcionará ya que DefinitelyTyped ya agrega automáticamente esta dependencia, pero no es suficiente para que TS trate correctamente sus mecanografiados.

Supongo que el problema es que TS no es consciente de la existencia del módulo hoist-non-react-statics , ya que el paquete hoist-react-statics no está presente en node_modules (es una pena que TS no pueda derivar el módulo existente desde @types/hoist-non-react-statics paquete, aunque puede haber una razón válida para tal comportamiento, por ejemplo, compatibilidad). Esta hipótesis se ve confirmada por el hecho de que la instalación manual de hoist-non-react-statics hace que su mecanografía funcione correctamente .

Entonces, @jamesreggio , supongo que debes agregar el paquete hoist-non-react-statics como una dependencia al package.json de @types/react-redux para solucionar este problema.

@surgeboris actualizado a 7.0.3 y agregado [email protected] y @types/[email protected] , solucionó un problema

La solución no funciona realmente para mí. Quizás estoy haciendo algo mal. Usando hilo 1.13

De acuerdo a todos, gracias por su paciencia.

Descubrí una solución y abrí un PR: # 33919.

Aparentemente, si usa la exportación de definición de tipo de estilo Node (con export = ), la forma correcta de importar es con import [name] = require([package name]) . No estoy familiarizado con los matices de estos patrones de importación / exportación, y solo estoy vagamente más seguro de que lo entiendo ahora 😆

Con suerte, los mantenedores de DefinitielyTyped pueden fusionarlo y publicarlo lo antes posible. Perdón de nuevo por la regresión.

Desafortunadamente, incluso con 7.0.4 que se lanzó recientemente, esto no me ha solucionado el problema.

Parece que aún falta la dependencia explícita de @types/hoist-non-react-statics .

en realidad, no, un npm i @types/react-redux instalado @types/hoist-non-react-statics . ¿No veo ningún problema?

Sí, la dependencia definitivamente aparece en su package.json :

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

Si aún tienen problemas, deben verificar que se hayan instalado las versiones correctas de todo.

(Específicamente, la dependencia se enumera como * , por lo que es posible que tenga una versión anterior de @types/hoist-non-react-statics que tal vez no tenga el tipo que npm cuenta como que satisface la dependencia).

Entonces, el problema tiene algunos matices.

El paquete hoist-non-react-statics incluyó sus propias tipificaciones hiperbásicas desde v2.2.0 hasta v3.0.0 , y si la versión de hoist-non-react-statics que se resuelve en la raíz de su proyecto en ese range, encontrará este error ya que las tipificaciones locales del paquete tienen prioridad sobre @types/hoist-non-react-statics .

Hay dos soluciones alternativas inmediatas:

1. Agregue hoist-non-react-statics@^3.3.0 a su proyecto como una dependencia.
2. Si usa hilo, agregue una anulación de resolución a su package.json como tal:
   "resolutions": { "hoist-non-react-statics": "^3.3.0" }

Ninguno de estos es óptimo, porque la mayoría de los desarrolladores (legítimamente) no son conscientes de la existencia de hoist-non-react-statics en primer lugar.

No estoy realmente seguro de cuál sería el enfoque óptimo aquí, pero sospecho que si pudiéramos enumerar una especificación de versión específica para @types/hoist-non-react-statics dentro de package.json por @types/react-redux , podría mitigar el impacto.

@weswigham : ¿sabe si es posible reemplazar la dependencia * con una dependencia de @types/hoist-non-react-statics con >=3.3.0 ?

@weswigham : ¿sabe si es posible reemplazar la dependencia

Si lo agrega explícitamente en package.json , ¿podría funcionar? AFAIK, no puede codificar versiones para dependencias implícitas o basadas en mapeo de rutas, pero podría estar equivocado.

@sandersn ¿ sabes algo más?

Acabo de abrir un PR que incluye una versión específica de @types/hoist-non-react-statics en el package.json . ¿Ojalá funcione? Ciertamente no podría hacer daño.

@weswigham , ¿te importaría revisar y aprobar?

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

No sé si esa es la solución correcta. Agregué una dependencia directa en hoist-non-react-statics@latest y solucionó todos los problemas.

Uf, @weswigham + @sandersn , no estoy seguro de qué hacer. La compilación de Travis falló porque agregué una especificación de versión específica para @types/hoist-non-react-statics . Vea el error aquí .

Es cierto que mi cambio a @types/react-redux _requiere_ un mínimo de 3.3.0 de @types/hoist-non-react-statics , así que siento que debería poder expresar esa restricción. ¿Puedes ayudarme a entender cómo hacer eso? (¿Debo hacer lo que dice el mensaje de error y agregarlo a dependenciesWhitelist.txt en types-publisher ? Parece un martillo demasiado grande).

No es un martillo demasiado grande: su problema es más o menos exactamente lo que describe el mensaje de registro (excepto que también volvimos a cambiar al paquete subyacente, no a los tipos de envío, toda la saga).

Genial, tengo un PR listo para fusionar en types-publisher : https://github.com/Microsoft/types-publisher/pull/595

@weswigham - ¿puedes aterrizarlo?

Se publicó a las 3:06 PDT (40 minutos antes de este comentario más o menos).

Bien, amigos, denle una oportunidad a @types/[email protected] y avíseme si todavía está roto.

Sigue siendo el mismo problema con @types/[email protected] . La única solución que me ha funcionado es requerir manualmente hoist-non-react-statics en mi proyecto

Secundado, todavía roto en @ types / [email protected].

@jamesreggio @weswigham No estoy seguro si has visto los comentarios pero te estoy haciendo ping, así que estamos seguros de que lo has visto

Sí, gracias, lo hice. Estaba enseñando React esta tarde en Cisco cuando esto mordió la clase. Después de una verificación rápida y encontré este hilo, los bajé a 7.0.1 y funcionó bien. Pero tengo un poco de rareza. Si agrego hoist-non-react-statics, funciona, como se describe anteriormente. Si desinstalo hoist-non-react-statics, sigue funcionando. Entonces, tal vez haya una dependencia real que se detecta allí, pero se mantiene incluso si elimina ese paquete. Si borro node_modules y package-lock.json y los reinstalo sin elevador, está roto nuevamente. Tengo que salir de aquí ahora, así que no puedo dedicar más tiempo a eso ahora mismo tratando de profundizar más. Alguien más podría encontrarlo más rápido de todos modos al estar más en sintonía con el paquete.

Voy a profundizar en esto nuevamente mañana, pero honestamente, necesito ayuda.
de un experto. Las complejidades del sistema de módulos TS me desconciertan. yo siento
como si hubiera hecho todo correctamente aquí ...

¿Pueden aquellos de ustedes que están teniendo el problema pegar un resumen de sus
package-lock.json o yarn.lock? Siento que esto puede ser un problema relacionado
al hecho inusual de que el polipasto-sin-reacción-estática incluía sus propias tipificaciones
durante un breve período en el pasado.

El jueves 21 de marzo de 2019 a las 20:03 Joel Mussman [email protected] escribió:

Sí, gracias, lo hice. Estaba enseñando React esta tarde en Cisco cuando este
mordió la clase. Después de una revisión rápida y encontré este hilo, los tenía de vuelta
hasta 7.0.1 y funcionó bien. Pero tengo un poco de rareza. Si agrego
hoist-non-react-statics funciona, como se describe anteriormente. Si desinstalo
hoist-non-react-statics sigue funcionando. Entonces tal vez haya un verdadero
dependencia que se recoge allí, pero se mantiene incluso si elimina
ese paquete. Si borro node_modules y package-lock.json y
vuelva a instalar sin polipasto, está roto de nuevo. Tengo que salir de aquí ahora
así que no puedo dedicar más tiempo a eso ahora mismo tratando de profundizar más.
Alguien más podría encontrarlo más rápido de todos modos estando más en sintonía con el
paquete.

-
Recibes esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/DefinitelyTyped/DefinitelyTyped/issues/33690#issuecomment-475477877 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AAyLva1P2ZGe86669tG7yu7fe1yMWWf-ks5vZEgHgaJpZM4bjI1Z
.

Aquí está mi package-lock.json : https://github.com/hellomouse/GNS/blob/greenkeeper/default/%40types/react-redux-7.0.5/dashboard/package-lock.json

Hola James,

Bien, entiendo lo que está mal en mi proyecto de clase. Todavía no sé cómo solucionarlo. Pero voy a publicar lo que sé, y tal vez alguien de Definitely Typed pueda ayudarlo.

react-router se instala antes que react-redux en la práctica de laboratorio anterior. La versión actual de react-router (hasta hace 4 días) era 4.3.1 y depende de [email protected]. Entonces, según las reglas, dado que nadie más dependía de hoist-non-react-statics, el paquete se instaló en el nivel superior de node_modules. Ahora [email protected] está instalado. Depende de [email protected]. Pero, dado que 2.2.5 ya está en el nivel superior, coloca 3.3.0 en la carpeta node_modules BAJO react-redux. Entonces, parece que la dependencia en @ types / react-redux de @ types / [email protected] no la encuentra porque no está en el nivel superior. Esas reglas no las he profundizado todavía, pero alguien más puede ser capaz de precisarlas de inmediato.

Los problemas de otras personas descritos anteriormente pueden ser muy similares a este escenario.

Pregunta relacionada: ¿cómo se supone que sepamos qué versión de @ types / react-redux se asigna a qué versión de react-redux? Como los números no se alinean, estoy perdido allí.

Hice un PR para solucionar este problema # 34090

¿No debería reabrirse este problema ya que el problema subyacente aún no se ha solucionado con la versión 7.0.5?
(sin agregar @ types / hoist-non-react-statics + hoist-non-react-statics a devDependencies)

El 100% está de acuerdo en que esto no debería cerrarse, aún está roto a menos que lo agregue manualmente a devDependancies

He presentado la solución adecuada que la gente de aquí parece ignorar desde el principio: # 34406

Entonces, ahora que el PR se fusionó, ¿los tipos react-redux tienen que actualizar la dependencia de hoist-non-react-statics?

Creo que sí. Pero creo que puede salirse con la suya eliminando la dependencia (desinstalarla) y volver a agregarla

De: Maurice [email protected]
Enviado: jueves 4 de abril de 2019 3:53:32 p.m.
Para: DefinitelyTyped / DefinitelyTyped
Cc: wolfy1339; Manual
Asunto: Re: [DefinitelyTyped / DefinitelyTyped] [@ types / react-redux] 'hoist-non-react-statics' no tiene miembro exportado 'NonReactStatics' (# 33690)

Entonces, ahora que el PR se fusionó, ¿los tipos react-redux tienen que actualizar la dependencia de hoist-non-react-statics?

-
Estás recibiendo esto porque estás suscrito a este hilo.
Responda a este correo electrónico directamente, véalo en GitHub https://github.com/DefinitelyTyped/DefinitelyTyped/issues/33690#issuecomment-480039685 , o silencie el hilo https://github.com/notifications/unsubscribe-auth/AEYfFbvvu7_1ZrU42jUU1kBX3u7_1ZrU42jUU1kBX3u5 .

¿Te refieres a las tipificaciones de React-Redux? Lo intentaré.

@ wolfy1339 https://github.com/DefinitelyTyped/DefinitelyTyped/pull/34406 no pareció solucionar el problema por mí. Creo que esto se debe a que hoist-non-react-statics se instalará dentro de @types/hoist-non-react-statics ( node_modules/@types/hoist-non-react-statics/node_modules/hoist-non-react-statics ), por lo que TS todavía usa los tipos de mi versión raíz ( node_modules/hoist-non-react-statics ).

En este punto valió la pena intentarlo. Alguien más tiene una idea?

@weswigham ¿Puede reabrir este problema?

Tuve un problema similar: usar yarn en lugar de npm para instalar dependencias resolvió mi problema. Publicar como nota al margen porque tal vez ustedes puedan intentarlo como una solución alternativa.

@ alan-mroczek Usamos hilo, así que no, esto no ayuda. Debe haber algo más en juego aquí. (bloquear archivo?)

No sé si entiendo el problema exacto, pero la solución que funcionó para mí con hilo fue agregar un campo de resoluciones a package.json.

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

Este problema todavía está activo para "@types/react-redux": "7.0.8", y establecer "resoluciones" no es una solución universal porque las "resoluciones" no funcionan en monorepo (espacios de trabajo de hilos)

Y no espero que sea la solución de todos modos. En mi opinión, el paquete @types después de su instalación debería "simplemente funcionar"

¿Podría la solución a todo este calvario ser agregarlo como una dependencia entre pares? Claro que no es infalible, pero es la única forma de garantizar que el mecanografiado encuentre la dependencia requerida

Obtenga Outlook para Android https://aka.ms/ghei36

De: Maurice [email protected]
Enviado: Lunes 29 de abril de 2019 12:30:06 PM
Para: DefinitelyTyped / DefinitelyTyped
Cc: wolfy1339; Mencionar
Asunto: Re: [DefinitelyTyped / DefinitelyTyped] [@ types / react-redux] 'hoist-non-react-statics' no tiene miembro exportado 'NonReactStatics' (# 33690)

Y no espero que sea la solución de todos modos. En mi opinión, el paquete @types https://github.com/types después de su instalación debería "simplemente funcionar"

-
Recibes esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub https://github.com/DefinitelyTyped/DefinitelyTyped/issues/33690#issuecomment-487649204 , o silencia el hilo https://github.com/notifications/unsubscribe-auth/ABDB6FL2OUVTTX754VHATFLPSV4PA5 .

Intenté muchas cosas, la degradación a @ types / react-redux 7.0.1 sigue siendo la única solución que funciona en este momento.

Lo mismo para mi ! Pero espero que algún día llegue una solución real (¡mantener esta dependencia obsoleta es extraño!).

Creo que tenemos que hacer lo mismo que # 34406 en las tipificaciones react-redux, y simplemente agregar una dependencia directa en hoist-non-react-statics , ya que NPM y Yarn no necesariamente van a poner la versión "correcta" de hoist-non-react-statics en el directorio de arriba @types/react-redux (lo que hará que TS tome el index.d.ts incorporado de v2.5 si está allí)

Esta es una solución realmente retorcida (y teóricamente podría mitigarse si TypeScript nos permitiera importar @types/hoist-non-react-statics/index.d.ts directamente, pero no veo ninguna alternativa razonable (y básicamente cualquier otra persona que dependa de @types/hoist-non-react-statics va a necesitar hacer lo mismo)

Creo que tenemos que hacer lo mismo que # 34406 en las tipificaciones react-redux, y simplemente agregar una dependencia directa en hoist-non-react-statics , ya que NPM y Yarn no necesariamente van a poner la versión "correcta" de hoist-non-react-statics en el directorio de arriba @types/react-redux (lo que hará que TS tome el index.d.ts incorporado de v2.5 si está allí)

Esta es una solución realmente retorcida (y teóricamente podría mitigarse si TypeScript nos permitiera importar @types/hoist-non-react-statics/index.d.ts directamente, pero no veo ninguna alternativa razonable (y básicamente cualquier otra persona que dependa de @types/hoist-non-react-statics va a necesitar hacer lo mismo)

¿Qué pasa con la importación desde '../hoist-non-react-statics'?
Por lo que veo, el paquete '@ types / hoist-non-react-statics' se instala automáticamente cuando se instala '@ types / react-redux', por lo que no debería haber riesgo de que se pierda.
Adjunté 2 archivos para mostrar una solución que funciona para mí.

hoist-non-react-statics_index.d.txt
react-redux_index.d.txt

Dada la forma en que funciona npm, no podemos garantizar que las mecanografías hoist-non-react-statics estén en un directorio hermano de react-redux . Dependiendo de qué otras dependencias haya instalado el usuario, podría ser un abuelo o un niño.

Esto todavía está roto para mí. Mi export default connect()(MyComponent) recibe un tipo any . Regresar a 7.0.1 arregla esta parte ... Esto parece ser un cambio en 7.0.2 .

Todavía sucede con 7.1.0 y degradar a 7.0.1 no es una opción para nosotros porque necesitamos TS 3.5.2 (con TS 3.4.5 , 7.0.1 funciona) y arroja el siguiente error con 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>>'.

Entonces, ¿alguna ... solución? No soy un experto en el tema, por lo que no puedo entender qué debo hacer con esto.

@tsakalidiskostas

Bueno, decidimos enviar una versión modificada de los tipos react-redux a nuestro repositorio. (Después de decidir no usar el paquete de parches . Lo cual puede ser una buena solución temporal si no le importa la solución alternativa de hilo necesaria).

Donde simplemente cambiamos la siguiente línea:

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

para:

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

Dado que no usamos estática, no nos perjudica, pero, por supuesto, puede que no sea una solución aceptable para todos.

¡Frio! Fui con la sugerencia de @alessioprestileo de cambiar

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

por

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

y cambiando la llamada a

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

y también funcionó para mí, en realidad estaba a punto de actualizarse cuando vi tu respuesta: D

Entonces, ¿publicaría una nueva versión en npm con correcciones? :)

¿Podemos simplemente hacer que los encargados de mantenimiento de la estática de no reacción de polipasto controlen los mecanografiados de nuevo en su repositorio?

Entonces ... ¿está sucediendo esto o debería seguir adelante con un cambio de bifurcación en eso?

Hola. También actualizamos a la última versión 7.1.1 de @types/react-redux con react-redux : 7.1.0 y estamos viendo este error con npm. Estoy confundido porque todas las entradas que se refieren a esto están cerradas.
Una rebaja a 7.0.1 soluciona este problema, pero causa un nuevo problema si usamos la última versión de 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'.

lo que lo convierte en una solución un poco triste.

La última versión (es decir, 7.1.1 ) de @types/react-redux no usa Shared<TInjectedProps, GetProps<C>> como restricción (precisamente por esa corrección en TS que señaló que la restricción era incorrecta) - tiene otra biblioteca que está forzando una inclusión anidada de una versión anterior de los tipos react-redux , creo.

Entonces, tengo la solución. Se llama "paquete de parches".

Si no ha usado el paquete de parches antes, ¡en realidad es bastante fácil! Simplemente agréguelo a su configuración, npm instálelo, luego simplemente presione un comando de paquete de parche en el módulo cambiado que ha arreglado y está funcionando y listo. Ahora tiene algunos módulos que residen en el paquete de parches que solo tienen los archivos modificados del módulo que estaba arreglando, nada demasiado lujoso o demasiado grande, etc. si puede eliminar fácilmente uno o dos archivos y todo está bien

Puedo confirmar que la instalación de hoist-non-react-statics resuelve este error para react-redux 7.1.0 y @types/react-redux 7.1.1 También estoy usando TypeScript 3.4.3.

Sin embargo, no sé por qué se ha resuelto este problema. ¿Existe una solución más razonable, sin tener que parchear el paquete o anular el árbol de resoluciones del módulo?

Tengo el mismo problema que @jalMogo

Sigo viendo este problema.

@jalMogo , hasta donde yo lo entiendo, este no es un problema con redux, sino con hoist-non-react-statics y es por eso que el problema está cerrado aquí. Hay varias soluciones alternativas en el hilo, pero sería mejor si alguien lo suficientemente capacitado le diera una solución a los montacargas.

No estoy de acuerdo en que se trate de un problema con la estática del polipasto que no reacciona. Es un problema con la descripción de redux, ya que termina mirando la versión anterior e incorrecta de hoist-non-react-statics si existe en el árbol node_modules, lo que ocurre cuando se instalan otras cosas como el enrutador. . La dependencia debe describirse correctamente y la nueva versión debe instalarse correctamente más cerca en el árbol de node_modules.

Esto sigue siendo un problema.

+1

Sigo recibiendo este problema y la pelusa dice que hay un error en el código. ¿Alguien todavía está trabajando en esto o se considera cerrado? Tengo todas las últimas versiones instaladas y todavía obtengo:

El espacio de nombres '"/ home / myhome / Projects / node_modules / hoist-non-react-statics / index"' no tiene un miembro exportado 'NonReactStatics'.ts (2694)

Este es definitivamente un problema de su parte. Solución alternativa: @types/hoist-non-react-statics debe aparecer como una dependencia en SU ​​proyecto para que funcione

Pero tengo eso y sigo teniendo el problema:
"dependencias": {
...
"@ types / hoist-non-react-statics": "^ 3.3.1",

está en mi package.json

Mi error. Necesitas hoist-non-react-statics

De: Robert Rehammar [email protected]
Enviado: Domingo 20 de octubre de 2019 1:50:51 AM
Para: DefinitelyTyped / DefinitelyTyped [email protected]
Cc: wolfy1339 [email protected] ; Mencione menció[email protected]
Asunto: Re: [DefinitelyTyped / DefinitelyTyped] [@ types / react-redux] 'hoist-non-react-statics' no tiene miembro exportado 'NonReactStatics' (# 33690)

Pero tengo eso y sigo teniendo el problema:
"dependencias": {
...
"@ types / hoist-non-react-statics": "^ 3.3.1",

está en mi package.json

-
Recibes esto porque te mencionaron.
Responder a este correo electrónico directamente, visualizarla en GitHub https://github.com/DefinitelyTyped/DefinitelyTyped/issues/33690?email_source=notifications&email_token=ABDB6FORFBHI575QMINWIQ3QPPWTXA5CNFSM4G4MRVM2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBYC7IY#issuecomment-544223139 , o darse de baja https://github.com/notifications/unsubscribe- auth / ABDB6FLBLRAIO2PIIGMMJY3QPPWTXANCNFSM4G4MRVMQ .

Tengo "hoist-non-react-statics": "^3.3.0" en mis dependencias y "@types/hoist-non-react-statics": "^3.3.1" en mis devDependencies y yo también tengo el problema. He confirmado que tampoco otras bibliotecas están incorporando versiones anteriores de estas.

También probé sin instalar explícitamente "@types/hoist-non-react-statics" (porque por lo que tengo entendido, el paquete principal ya debería tener mecanografiado incluido), pero con el mismo resultado.

Cualquiera que se enfrente a este problema debe proporcionar una reproducción ejecutable, de lo contrario no podemos ofrecer ninguna ayuda.

Lo siento, el proyecto que estoy experimentando no es de código abierto y no tengo tiempo para crear un proyecto separado para mostrarlo. Sin embargo, lo que sí noté es que el proyecto no tuvo problemas hasta que habilité allowJs: true en tsconfig.json . Sin esta configuración, todo funcionaba bien. Espero eso ayude.

agregar la 'estática de elevación sin reacción' parece haberlo solucionado aquí.

repro simplemente está instalando @ types / react-redux y luego importando cualquier cosa en react-redux en un archivo tsx.

Una forma de solucionar este problema es agregar "skipLibCheck": true en tsconfig.json. No es la mejor solución, pero como solución alternativa, se puede utilizar.

Creo que esto sucede porque mecanografiado resuelve las cosas en este orden:

1. package/package.json[types]
2. @types/package
3. package (todo excepto el campo types )

Por qué lo hace es un misterio para mí, pero está documentado aquí: https://www.typescriptlang.org/docs/handbook/module-resolution.html#how -typescript-resolves-modules

Entonces, por ejemplo, si tiene la siguiente estructura de directorio:

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

Entonces mecanografiado hará lo siguiente:

1. no se obtienen tipos de node_modules/@types/react-redux/node_modules/hoist-non-react-statics porque la versión actual no incluye tipos
2. tener éxito en encontrar tipos de node_modules/hoist-non-react-statics (la versión anterior) porque su package.json tiene un campo types

por lo tanto, como otros han mencionado, puede solucionar el problema agregando una dependencia en su proyecto en el último hoist-non-react-statics , porque eso no tiene un campo types en package.json por lo que hace que el paso 2 falle.

Irónicamente, también puede solucionarlo agregando una dependencia en su proyecto en un hoist-non-react-statics más antiguo, por ejemplo, 3.0.0. Esto funciona porque obliga a que se instale la versión correcta (3.3.0) en node_modules/@types/react-redux/node_modules/types/hoist-non-react-statics , donde se resuelve antes: confuso:

Entonces tengo dos preguntas:

1. ¿Por qué el mecanografiado trata el campo types especialmente de esta manera, y viene antes o después de los paquetes @types dependiendo de si se usa o no el campo types ?
2. Si hoist-non-react-statics alguna vez tuvo tipos incorporados, ¿por qué fueron renegados aquí? Esto no sería un problema si los tipos estuvieran integrados en package. No veo cómo yarn / NPM puede lidiar adecuadamente con paquetes separados para código y tipos, ya que no saben cómo están conectados los dos.

Este problema parece haber resurgido con las últimas versiones del paquete, es decir:

[email protected]
@types/[email protected]

Pude resolver esto al incluir manualmente los siguientes paquetes en mi package.json :

[email protected]
@types/[email protected]

Debido a que los paquetes hoist-non-react-statics después de mi npm install inicial, había duplicados de estos paquetes en mi carpeta node_modules . Correr npm dedupe aclaró eso.

¡Espero que ayude a cualquiera que venga!

También tuve este problema, ¡alabado sea la solución de @DannyDelott !

También tuve este problema, ¡alabado sea la solución de @DannyDelott !

La solución más rápida por ahora sin contaminar su package.json con dependencias que no necesita directamente es eliminar @types/react-redux

npm remove @types/react-redux

Una vez que veamos que este problema se ha resuelto, podemos volver a colocarlo.

El problema sigue ocurriendo y la única forma de solucionarlo es agregar las dependencias mencionadas a su proyecto. Sin embargo, esto no es ideal, ¡así que espero que lo solucionemos pronto!

Sigo notando este problema.

Para cualquiera que esté dispuesto a seguir desarrollándose mientras haya una solución estable, puede usar el typedef a continuación:

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

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

Esta no es la solución ideal, pero al menos es útil para evitar errores de compilación con TS