Definitelytyped: [@ types / react-redux] 'hoist-non-react-statics' не имеет экспортированного члена 'NonReactStatics'

Созданный на 7 мар. 2019  ·  84Комментарии  ·  Источник: DefinitelyTyped/DefinitelyTyped

  • [x] Я пробовал использовать пакет @types/react-redux , и у меня возникли проблемы.
  • [x] Я пробовал использовать последнюю стабильную версию tsc. https://www.npmjs.com/package/typescript
  • [x] У меня вопрос, который не подходит для StackOverflow . (Пожалуйста, задавайте там любые уместные вопросы).
  • [x] [Упоминание] (https://github.com/blog/821-mention-somebody-they-re-notified) авторов (см. Definitions by: в index.d.ts ), чтобы они могли реагировать.

@jamesreggio @JounQin

обновление с @types/react-redux 7.0.1 до @types/react-redux 7.0.2 дает следующую ошибку:

'/node_modules/hoist-non-react-statics' has no exported member 'NonReactStatics'.

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

похоже, что это было введено здесь: https://github.com/DefinitiTyped/DefinitiTyped/commit/8b1beff944f6c7bf913b6fcee31fb5f7129064a7

Самый полезный комментарий

Я могу ошибаться, но я думаю, что проблема может быть проще,

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

должно быть

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

переход на @ types / react-redux 7.0.1 - быстрое решение, пока оно не будет исправлено.

Все 84 Комментарий

Ой. В этом изменении я ввел зависимость от @types/hoist-non-react-statics , но не как зависимость. Эта проблема в том, что я не уверен, где объявить ее как зависимость, поскольку типы зависят только от типов.

@JounQin , ты можешь помочь мне понять, как это исправить. Нужно ли нам добавить ///<reference или что-то добавить к package.json ?

В качестве временного обходного пути вы можете добавить в свой проект npm install --dev @types/hoist-non-react-statics .

Я могу ошибаться, но я думаю, что проблема может быть проще,

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

должно быть

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

переход на @ types / react-redux 7.0.1 - быстрое решение, пока оно не будет исправлено.

У меня тоже есть эта проблема. Переход на 7.0.1 помог

То же самое.

Ой. В этом изменении я ввел зависимость от @types/hoist-non-react-statics , но не добавил ее как зависимость

ОпределенноTyped автоматически добавил @types/hoist-non-react-statics в качестве зависимости к @types/react-redux , но (очевидно) этого было недостаточно для того, чтобы ваш ввод работал.

В качестве временного обходного пути вы можете добавить в свой проект npm install --dev @types/hoist-non-react-statics .

Нет, это не сработает, так как эта зависимость уже автоматически добавлена ​​DefinельнымTyped, но этого недостаточно, чтобы TS правильно обрабатывал ваш ввод.

Я предполагаю, что проблема в том, что TS не знает о существовании модуля hoist-non-react-statics , поскольку сам пакет hoist-react-statics отсутствует в node_modules (жаль, что TS не может получить модуль, существующий, поскольку из @types/hoist-non-react-statics package, хотя для такого поведения может быть веская причина, например совместимость). Эта гипотеза подтверждается тем фактом, что ручная установка hoist-non-react-statics действительно заставляет вашу типизацию работать правильно .

Итак, @jamesreggio, я думаю, вам нужно добавить пакет hoist-non-react-statics как зависимость от package.json из @types/react-redux , чтобы исправить эту проблему.

@surgeboris обновился до 7.0.3 и добавил [email protected] и @types/[email protected] , исправил проблему

Исправление на самом деле не работает для меня. Может я что-то не так делаю. Использование пряжи 1.13

Хорошо всем, спасибо за терпение.

Я нашел решение и открыл PR: # 33919.

По-видимому, если вы используете экспорт определения типа в стиле узла (с export = ), правильный способ импорта - с помощью import [name] = require([package name]) . Я довольно незнаком с нюансами этих шаблонов импорта / экспорта, и я лишь смутно уверен, что понимаю это сейчас 😆

Надеюсь, разработчики DefinitielyTyped смогут объединить это и выпустить как можно скорее. Еще раз извините за регресс.

К сожалению, даже с недавно выпущенным 7.0.4 это не устранило проблему для меня.

Похоже, явная зависимость от @types/hoist-non-react-statics все еще отсутствует.

собственно нет - свежая npm i @types/react-redux установлена @types/hoist-non-react-statics . Я не вижу проблем?

Ага, зависимость определенно указана в его package.json :

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

Если у вас все еще есть проблемы, вам следует дважды проверить, были ли установлены правильные версии всего.

(В частности, зависимость указана как * , поэтому у вас может быть более старая версия @types/hoist-non-react-statics , в которой, возможно, отсутствует тип, который npm считается удовлетворяющим зависимости?)

Итак, проблема имеет несколько нюансов.

Пакет hoist-non-react-statics включал свои собственные гипер-базовые типы от v2.2.0 до v3.0.0 , и если версия hoist-non-react-statics которая разрешается в корне вашего проекта, находится в этом range, вы столкнетесь с этой ошибкой, поскольку типизация локального пакета имеет приоритет над @types/hoist-non-react-statics .

Есть два немедленных обходных пути:

  1. Добавьте hoist-non-react-statics@^3.3.0 в свой проект в качестве зависимости.
  2. Если вы используете пряжу, добавьте переопределение разрешения к вашему package.json как таковое:
    "resolutions": { "hoist-non-react-statics": "^3.3.0" }

Ни один из них не является оптимальным, потому что большинство разработчиков (по праву) не знают о существовании hoist-non-react-statics в первую очередь.

Я не совсем уверен, какой будет здесь оптимальный подход, но подозреваю, что если бы мы могли указать конкретную версию для @types/hoist-non-react-statics внутри package.json для @types/react-redux , мы может смягчить воздействие.

@weswigham - знаете ли вы, можно ли заменить * на зависимость от @types/hoist-non-react-statics на >=3.3.0 ?

@weswigham - знаете ли вы, возможно ли заменить

Если вы явно добавите его в package.json это может сработать? AFAIK вы не можете жестко запрограммировать версии для подразумеваемых зависимостей или зависимостей на основе сопоставления путей, но я могу ошибаться.

@sandersn знаете что-нибудь еще?

Я только что открыл PR, который включает конкретную версию @types/hoist-non-react-statics в package.json . Надеюсь, это сработает? Конечно, не повредит.

@weswigham , не могли бы вы просмотреть и одобрить?

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

Я не знаю, правильное ли это исправление. Я добавил прямую зависимость от hoist-non-react-statics@latest и устранил все проблемы.

Ух , @sandersn - не знаю, что делать. Сборка Travis завершилась неудачно, потому что я добавил спецификацию версии для @types/hoist-non-react-statics . См. Ошибку здесь .

Это правда, что мое изменение на @types/react-redux _requires_ минимум 3.3.0 из @types/hoist-non-react-statics , поэтому я чувствую, что могу выразить это ограничение. Вы можете помочь мне понять, как это сделать? (Следует ли мне сделать то, что написано в сообщении об ошибке, и добавить его к dependenciesWhitelist.txt в types-publisher ? Это похоже на слишком большой молоток.)

Это не слишком большой молоток - ваша проблема в значительной степени связана с тем, что описывает сообщение журнала (за исключением того, что мы также снова переключились на базовый пакет, а не на типы доставки, что и есть сага).

Круто, у меня есть PR, готовый объединиться на types-publisher : https://github.com/Microsoft/types-publisher/pull/595

@weswigham - ты сможешь его посадить?

Он опубликован в 3:06 PDT (за 40 минут до этого комментария или около того).

Ладно, ребята, попробуйте @types/[email protected] и дайте мне знать, если вы все еще сломаны.

По-прежнему та же проблема с @types/[email protected] . Единственное исправление, которое сработало для меня, - вручную потребовать hoist-non-react-statics в моем проекте.

Подчиненный, все еще не работает в @ types / [email protected].

@jamesreggio @weswigham Я не уверен, видели ли вы комментарии, но пишу вам, поэтому мы уверены, что вы это видели

Да, спасибо. Сегодня днем ​​я преподавал React в Cisco, когда этот урок закончился. После быстрой проверки, и я нашел эту тему, я вернул их к 7.0.1, и все заработало. Но у меня есть небольшая странность. Если я добавлю статику подъема без реакции, она будет работать, как описано выше. Если я удалю статику подъема без реакции, она продолжит работать. Так что, возможно, существует реальная зависимость, которая возникает там, но остается, даже если вы удалите этот пакет. Если я удалю node_modules и package-lock.json и переустановлю без подъема, он снова сломается. Мне нужно убираться отсюда сейчас, поэтому я не могу больше тратить на это время, пытаясь копать глубже. Кто-то другой может найти это быстрее в любом случае, будучи более согласованным с пакетом.

Я собираюсь разобраться в этом снова завтра, но, честно говоря, мне нужна помощь
от эксперта. Тонкости модульной системы TS сбивают меня с толку. я чувствую
вроде я тут все сделал правильно ...

Могут ли те из вас, у кого возникла проблема, вставить суть вашего
package-lock.json или yarn.lock? Я чувствую, что это может быть проблема, связанная с
к необычному факту, что статика, не реагирующая на подъем, включала свои собственные типы
на короткий период в прошлом.

В четверг, 21 марта 2019 г., в 20:03 Джоэл Муссман [email protected] написал:

Да, спасибо. Я преподавал React сегодня в Cisco, когда это
укусил класс. После быстрой проверки, и я нашел эту ветку, я вернул их
до 7.0.1, и он работал нормально. Но у меня есть небольшая странность. Если я добавлю
подъем-не-реагировать-статика работает, как описано выше. Если я удалю
подъем-не-реагировать-статика продолжает работать. Так что, может быть, есть настоящая
зависимость, которая возникает там, но остается, даже если вы удалите
этот пакет. Если я удалю node_modules и package-lock.json и
переустановить без подъемника, он снова сломан. Мне нужно убираться отсюда сейчас,
так что сейчас я не могу больше тратить на это время, пытаясь копнуть глубже.
Кто-то другой может найти это быстрее в любом случае, будучи более настроенным на
упаковка.

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/DefinitiTyped/DefinitiTyped/issues/33690#issuecomment-475477877 ,
или отключить поток
https://github.com/notifications/unsubscribe-auth/AAyLva1P2ZGe86669tG7yu7fe1yMWWf-ks5vZEgHgaJpZM4bjI1Z
.

Привет, Джеймс,

Хорошо, я понимаю, что не так в моем проекте класса. Пока не знаю, как это исправить. Но я собираюсь выложить то, что знаю, и, может быть, кто-нибудь из Определенно Typed сможет вам помочь.

response-router устанавливается до react-redux в предыдущей лабораторной работе. Текущая версия response-router (до 4 дней назад) была 4.3.1 и зависит от [email protected]. Итак, по правилам, поскольку никто другой не зависел от статики hoist-non-react-statics, пакет был установлен на верхнем уровне node_modules. Теперь [email protected] установлен. Это зависит от [email protected]. Но, поскольку 2.2.5 уже находится на верхнем уровне, он помещает 3.3.0 в папку node_modules ПОД response-redux. Таким образом, похоже, что зависимость в @ types / react-redux от @ types /

Другие проблемы, описанные ранее, могут быть очень похожи на этот сценарий.

Связанный вопрос: как мы должны узнать, какая версия @ types / react-redux соответствует какой версии react-redux? Поскольку числа не совпадают, я потерялся там.

Я сделал пиар, чтобы исправить эту проблему # 34090

Не следует ли повторно открыть эту проблему, поскольку основная проблема еще не устранена в версии 7.0.5?
(без добавления @ types / hoist-non-react-statics + hoist-non-react-statics к devDependencies)

100% согласны, что это не должно быть закрыто, все равно сломано, если вы вручную не добавите в devDependancies

Я зарегистрировал правильное исправление, которое люди здесь игнорировали с самого начала: # 34406

Итак, теперь, когда PR объединен, типы response-redux должны обновить зависимость от статики hoist-non-react-statics?

Я так думаю. Но я думаю, вам удастся удалить зависимость (удалить ее) и повторно добавить ее.


От: Морис [email protected]
Отправлено: четверг, 4 апреля 2019 г., 15:53:32
Кому: ОпределенноТипед / ОпределенноТипед
Копия: wolfy1339; Руководство по эксплуатации
Тема: Re: [ОпределенноТипед / ОпределенноТипед] [@ types / react-redux] 'hoist-non-react-statics' не имеет экспортированного члена 'NonReactStatics' (# 33690)

Итак, теперь, когда PR объединен, типы response-redux должны обновить зависимость от статики hoist-non-react-statics?

-
Вы получаете это, потому что подписаны на эту ветку.
Ответьте на это электронное письмо напрямую, просмотрите его на GitHub https://github.com/DefinitiTyped/DefinitiTyped/issues/33690#issuecomment-480039685 или отключите поток https://github.com/notifications/unsubscribe-auth/AEYfFbvvu7_1Zvjk1GU4U3

Вы имеете в виду типизацию react-redux? Я попробую это.

@ wolfy1339 https://github.com/DefinitiTyped/DefinitiTyped/pull/34406 , похоже, не решил проблему для меня. Я думаю, это потому, что hoist-non-react-statics будет установлен внутри @types/hoist-non-react-statics ( node_modules/@types/hoist-non-react-statics/node_modules/hoist-non-react-statics ), поэтому TS по-прежнему использует типы из моей корневой версии ( node_modules/hoist-non-react-statics ).

На этом этапе стоило попробовать. У кого-нибудь еще есть идея?

@weswigham Можете ли вы снова открыть этот выпуск?

Была аналогичная проблема - использование пряжи вместо npm для установки зависимостей разрешило мою проблему. Публикация в качестве примечания, потому что, возможно, вы, ребята, можете попробовать это в качестве обходного пути.

@ alan-mroczek Мы используем пряжу, поэтому нет, это не помогает. Здесь должно быть что-то еще. (файл блокировки?)

Я не знаю, понимаю ли я точную проблему, но решение, которое сработало для меня с yarn, заключалось в добавлении поля разрешений в package.json.

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

Эта проблема все еще активна для "@types/react-redux": "7.0.8", и установка «разрешений» не является универсальным решением, потому что «разрешения» не работают в монорепозитории (рабочие области пряжи)

И я в любом случае не ожидаю, что это станет решением. На мой взгляд, пакет @types после его установки должен "просто работать".

Может ли решением всего этого испытания добавить его как взаимозависимость? Конечно, это не надежно, но это единственный способ гарантировать, что машинописный текст найдет требуемую зависимость.

Получите Outlook для Android https://aka.ms/ghei36


От: Морис [email protected]
Отправлено: понедельник, 29 апреля 2019 г., 12:30:06
Кому: ОпределенноТипед / ОпределенноТипед
Копия: wolfy1339; Упомянуть
Тема: Re: [ОпределенноТипед / ОпределенноТипед] [@ types / react-redux] 'hoist-non-react-statics' не имеет экспортированного члена 'NonReactStatics' (# 33690)

И я в любом случае не ожидаю, что это станет решением. На мой взгляд, пакет @types https://github.com/types после его установки должен "просто работать".

-
Вы получаете это, потому что вас упомянули.
Ответьте на это электронное письмо напрямую, просмотрите его на GitHub https://github.com/DefinitiTyped/DefinitiTyped/issues/33690#issuecomment-487649204 или отключите поток https://github.com/notifications/unsubscribe-auth/ABDB6FL2OUVTFANC754V

Пробовал много чего, понижение до @ types / react-redux 7.0.1 по-прежнему является единственным исправлением, которое работает на данный момент.

То же самое для меня ! Но я надеюсь, что однажды настанет время для настоящего исправления (сохранять эту устаревшую зависимость странно!).

Я думаю, что нам нужно сделать то же самое, что и # 34406 в типах response-redux, и просто добавить прямую зависимость от hoist-non-react-statics , поскольку NPM и Yarn не обязательно будут помещать "правильную" версию hoist-non-react-statics в каталоге выше @types/react-redux (что заставит TS захватить встроенный index.d.ts версии 2.5, если он там есть)

Это действительно грубое решение (и теоретически его можно было бы смягчить, если бы TypeScript позволил нам напрямую импортировать @types/hoist-non-react-statics/index.d.ts , но я не вижу никаких разумных альтернатив (и в основном всех, кто зависит от @types/hoist-non-react-statics нужно будет сделать то же самое)

Я думаю, что нам нужно сделать то же самое, что и # 34406 в типах response-redux, и просто добавить прямую зависимость от hoist-non-react-statics , поскольку NPM и Yarn не обязательно будут помещать "правильную" версию hoist-non-react-statics в каталоге выше @types/react-redux (что заставит TS захватить встроенный index.d.ts версии 2.5, если он там есть)

Это действительно грубое решение (и теоретически его можно было бы смягчить, если бы TypeScript позволил нам напрямую импортировать @types/hoist-non-react-statics/index.d.ts , но я не вижу никаких разумных альтернатив (и в основном всех, кто зависит от @types/hoist-non-react-statics нужно будет сделать то же самое)

А как насчет импорта из "../hoist-non-react-statics"?
Насколько я понимаю, пакет «@ types / hoist-non-react-statics» автоматически устанавливается при установке «@ types / response-redux», поэтому не должно быть риска его пропуска.
Я прикрепил 2 файла, чтобы показать решение, которое мне подходит.

подъем-не-реагировать-statics_index.d.txt
реагировать-redux_index.d.txt

Учитывая способ, которым работает npm, мы не можем гарантировать, что типы hoist-non-react-statics будут находиться в родственном каталоге react-redux . В зависимости от того, какие другие зависимости пользователь установил, это может быть дедушка или бабушка или ребенок.

Это все еще не работает для меня. Моему export default connect()(MyComponent) присваивается тип any . Возврат к 7.0.1 исправляет эту часть ... Похоже, это изменение в 7.0.2 .

По-прежнему происходит с 7.1.0 и понижение до 7.0.1 не вариант для нас, потому что нам нужны TS 3.5.2 (с TS 3.4.5 , 7.0.1 действительно работает), и это вызывает следующую ошибку с 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>>'.

Итак, какие ... обходные пути? Я не эксперт в этом вопросе, поэтому не понимаю, что мне с этим делать.

@tsakalidiskostas

Итак, мы решили, что зафиксируем модифицированную версию типов react-redux в нашем репо. (После принятия решения не использовать пакет исправлений . Что может быть хорошим временным решением, если вы не возражаете против необходимого обходного пути пряжи.)

Где мы просто меняем следующую строку:

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

к:

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

Поскольку мы не используем статику, это нам не повредит, но это, конечно, может быть приемлемым решением не для всех.

Прохладный! Я пошел с предложением @alessioprestileo изменить

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

для

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

и изменение вызова на

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

и это сработало для меня, на самом деле как раз собирался обновиться, когда я увидел ваш ответ: D

Так вы бы опубликовали новую версию в npm с исправлениями? :)

Можем ли мы просто заставить тех, кто поддерживает статику подъема без реагирования, проверять вводимые данные обратно в свое репо?

Итак .. это происходит, или я должен пойти дальше, изменив вилку?

Всем привет. Мы также обновили до последней версии 7.1.1 @types/react-redux с помощью react-redux : 7.1.0 и мы видим эту ошибку с npm. Я сбит с толку, так как все билеты, относящиеся к этому, закрыты.
Переход на 7.0.1 действительно решает эту проблему, но вызывает новую проблему, если мы используем последнюю версию 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'.

что делает это своего рода печальным обходным решением.

Последняя версия (т.е. 7.1.1 ) @types/react-redux не использует Shared<TInjectedProps, GetProps<C>> в качестве ограничения (именно из-за того исправления в TS, которое указывало на неправильное ограничение) - у вас есть другая библиотека, которая, как мне кажется, требует вложенного включения более старой версии типов react-redux .

Итак, у меня есть обходной путь. Это называется «патч-пакет».

Если вы раньше не использовали пакет исправлений, это на самом деле довольно просто! Вы просто добавляете его в свою конфигурацию, устанавливаете npm, затем просто нажимаете команду пакета исправлений для измененного модуля, который вы исправили и который работает, и вуаля. Теперь у вас есть несколько модулей, которые находятся в пакете патчей, в котором есть только измененные файлы модуля, который вы исправляли, ничего слишком необычного или слишком большого и т. Д. Ошибка исправлена, зависимость не теряется, поэтому, когда / если они исправят вы можете легко удалить один или два файла, и все в порядке

Я могу подтвердить, что установка hoist-non-react-statics устраняет эту ошибку для react-redux 7.1.0 и @types/react-redux 7.1.1. Я также использую Typescript 3.4.3.

Однако я не знаю, почему этот вопрос закрыт. Есть ли более разумное решение без исправления пакета или переопределения дерева разрешений модуля?

У меня та же проблема, что и у @jalMogo

Все еще наблюдаю эту проблему.

@jalMogo, насколько я понимаю, это проблема не с редукцией, а с подъемом-не-реакцией-статикой, и поэтому здесь проблема закрыта. В ветке есть несколько обходных путей, но было бы лучше, если бы кто-то достаточно опытный дал исправление подъемникам.

Я не согласен с тем, что это проблема статики без реакции подъемника. Это проблема с описанием redux, поскольку в конечном итоге он смотрит на старую и неправильную версию hoist-non-react-statics, если она существует в дереве node_modules, что происходит, когда некоторые другие вещи, такие как маршрутизатор, установлены . Зависимость необходимо правильно описать, а новую версию правильно установить ближе в дереве node_modules.

Это все еще проблема.

+1

У меня все еще возникает эта проблема, и ворс говорит, что в коде есть ошибка. Кто-нибудь еще над этим работает или это считается закрытым? У меня установлены все последние версии, но я все еще получаю:

Пространство имен '"/ home / myhome / Projects / node_modules / hoist-non-react-statics / index"' не имеет экспортированного члена 'NonReactStatics'.ts (2694)

Это определенно проблема с их стороны. Обходной путь: @types/hoist-non-react-statics должен быть указан как зависимость в ВАШЕМ проекте, чтобы он работал

Но у меня это есть, и проблема до сих пор возникает:
"dependencies": {
...
"@ types / hoist-non-react-statics": "^ 3.3.1",

находится в моем package.json

Виноват. Вам нужно hoist-non-react-statics


От: Роберт Рехаммар [email protected]
Отправлено: Воскресенье, Октябрь 20, 2019 1:50:51 AM
Кому: ОпределенноTyped / ОпределенноTyped Определенно[email protected]
Копия: wolfy1339 [email protected] ; Упомяните упоминание@noreply.github.com
Тема: Re: [ОпределенноТипед / ОпределенноТипед] [@ types / react-redux] 'hoist-non-react-statics' не имеет экспортированного члена 'NonReactStatics' (# 33690)

Но у меня это есть, и проблема до сих пор возникает:
"dependencies": {
...
"@ types / hoist-non-react-statics": "^ 3.3.1",

находится в моем package.json

-
Вы получаете это, потому что вас упомянули.
Ответить на это сообщение непосредственно, просматривать его на GitHub https://github.com/DefinitelyTyped/DefinitelyTyped/issues/33690?email_source=notifications&email_token=ABDB6FORFBHI575QMINWIQ3QPPWTXA5CNFSM4G4MRVM2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBYC7IY#issuecomment-544223139 или отписки https://github.com/notifications/unsubscribe- auth / ABDB6FLBLRAIO2PIIGMMJY3QPPWTXANCNFSM4G4MRVMQ .

У меня есть "hoist-non-react-statics": "^3.3.0" в моих зависимостях и "@types/hoist-non-react-statics": "^3.3.1" в моих devDependencies, и у меня тоже есть проблема. Я подтвердил, что никакие другие библиотеки также не используют более старые версии.

Я также пробовал без явной установки "@types/hoist-non-react-statics" (потому что, насколько я понимаю, в основной пакет уже должны быть включены типизации), но с тем же результатом.

Любой, кто сталкивается с этой проблемой, должен предоставить работоспособное воспроизведение, иначе мы не сможем предложить никакой помощи.

Мне очень жаль, но проект, который я использую, не является открытым, и у меня нет времени на создание отдельного проекта для его демонстрации. Однако я заметил, что в проекте не было проблем, пока я не включил allowJs: true в tsconfig.json . Без этой настройки все работало нормально. Надеюсь, это поможет.

добавление «статики-не-реагирования», похоже, исправило это здесь.

repro просто устанавливает @ types / response-redux, а затем импортирует что-либо в react-redux в файл tsx.

Один из способов решить эту проблему - добавить skipLibCheck: true в tsconfig.json. Это не лучшее решение, но его можно использовать в качестве обходного пути.

Я думаю, это происходит потому, что машинописный текст решает все в следующем порядке:

  1. package/package.json[types]
  2. @types/package
  3. package (все, кроме поля types )

Почему это происходит, для меня загадка, но это описано здесь: https://www.typescriptlang.org/docs/handbook/module-resolution.html#how -typescript-resolves-modules

Так, например, если у вас следующая структура каталогов:

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

Тогда машинописный текст будет делать следующее:

  1. не удается получить типы из node_modules/@types/react-redux/node_modules/hoist-non-react-statics потому что текущая версия не включает типы
  2. удалось найти типы из node_modules/hoist-non-react-statics (старая версия), потому что в его package.json есть поле types

следовательно, как уже упоминалось другими, вы можете решить проблему, добавив в свой проект зависимость от последнего hoist-non-react-statics , потому что у него нет поля types в package.json поэтому делает шаг 2 неудачным.

Как ни странно, вы также можете исправить это, добавив в свой проект зависимость от более старого hoist-non-react-statics , например 3.0.0. Это работает, потому что принудительно устанавливает правильную версию (3.3.0) в node_modules/@types/react-redux/node_modules/types/hoist-non-react-statics , где она решена ранее: confounded:

Итак, у меня есть два вопроса:

  1. Почему машинописный текст обрабатывает поле types специально таким образом, и оно появляется до или после пакетов @types зависимости от того, используется ли поле types или нет?
  2. Если в hoist-non-react-statics когда-то были встроенные типы, почему они отказались от этого здесь? Это не было бы проблемой, если бы типы были встроены в package. Я не вижу, как yarn / NPM может правильно работать с отдельными пакетами для кода и типов, поскольку они не знают, как они связаны.

Эта проблема, похоже, возникла снова в последних версиях пакета, а именно:

[email protected]
@types/[email protected]

Мне удалось решить эту проблему, вручную включив следующие пакеты в мои package.json :

[email protected]
@types/[email protected]

Поскольку пакеты hoist-non-react-statics после моего начального npm install были дубликаты этих пакетов в моей папке node_modules . Запуск npm dedupe прояснил это.

Надеюсь, что это поможет всем, кто придет!

У меня тоже была эта проблема - хвала решению @DannyDelott !

У меня тоже была эта проблема - хвала решению @DannyDelott !

Самое быстрое решение на данный момент без загрязнения вашего package.json зависимостями, которые вам напрямую не нужны, - это удалить @types/react-redux

npm remove @types/react-redux

Как только мы увидим, что проблема решена, мы сможем вернуть ее.

Проблема все еще возникает, и единственный способ исправить это - добавить упомянутые зависимости в ваш проект. Однако это не идеально, так что, надеюсь, мы скоро исправим!

Все еще замечаю эту проблему.

Для всех, кто хочет продолжать разработку, пока будет выпущено стабильное исправление, вы можете использовать typedef ниже:

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

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

Это не идеальное решение, но, по крайней мере, полезно для предотвращения ошибок сборки с помощью TS.

Была ли эта страница полезной?
0 / 5 - 0 рейтинги