Definitelytyped: node_modules/@types/react-native/globals.d.ts (36,15): повторяющийся идентификатор FormData.

То же самое

Зачем вообще был добавлен @ types / react-native? У меня есть реактивный веб-проект, почему мне нужно устанавливать шрифты, которые я не использую?

Исправлено установкой compilerOptions.types вручную

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

У меня такая же проблема.

Здесь та же проблема.
Поскольку в моем проекте есть несколько определений типов, я установил фиксированную зависимость @types/styled-components от предыдущей версии.

Я думаю, что добавление типов явно в tsconfig.json - плохое решение.
Было бы лучше разделить типы для styled-components для Интернета и для нативного.

У меня проблема с этой FormData, я использую typescript: 3.3.333 вот мои package.json и tsconfig.json

ПАКЕТ JSON
"dependencies": { "@material-ui/core": "^3.9.2", "@types/react-loadable": "^5.5.0", "@types/react-router-dom": "^4.3.1", "prettier": "^1.16.4", "react": "^16.8.4", "react-dom": "^16.8.4", "react-loadable": "^5.5.0", "react-router-dom": "^5.0.0", "react-scripts-ts": "3.1.0", "styled-components": "^4.1.3" }, "devDependencies": { "@types/jest": "^24.0.11", "@types/node": "^11.11.3", "@types/react": "^16.8.8", "@types/react-dom": "^16.8.2", "@types/styled-components": "^4.1.12", "eslint": "5.3.0", "eslint-config-airbnb-base": "13.1.0", "eslint-plugin-import": "^2.14.0", "typescript": "^3.3.3333" }

TSCONFIG JSON
{ "compilerOptions": { "baseUrl": ".", "outDir": "build/dist", "module": "esnext", "target": "es5", "lib": ["es6", "dom"], "sourceMap": true, "allowJs": true, "jsx": "react", "moduleResolution": "node", "rootDir": "src", "forceConsistentCasingInFileNames": true, "noImplicitReturns": true, "noImplicitThis": true, "noImplicitAny": true, "importHelpers": true, "strictNullChecks": true, "suppressImplicitAnyIndexErrors": true, "noUnusedLocals": true, "esModuleInterop": true, "types": ["styled-components", "react", "react-dom", "jest"] }, "exclude": [ "node_modules", "build", "scripts", "acceptance-tests", "webpack", "jest", "src/setupTests.ts" ] }

У меня точно такая же проблема. К счастью, мне удалось решить эту проблему, заблокировав версию @types/styled-components на 4.1.8

То же самое и здесь, мне пришлось либо откатиться к предыдущей версии, либо добавить сценарий postinstall, чтобы удалить response-native из node_modules

Как вообще можно использовать стилизованные компоненты в сети, если их зависимости по умолчанию конфликтуют с библиотеками dom ?!
Это безумие!

У меня такая же проблема, и я также заметил, что не все авторы были уведомлены. Эти два отсутствуют: @ eps1lon @flavordaaave

@ArthurBrito спасибо, список авторов обновлен.

Эта проблема возникает и у меня. @ types / react-native не должно быть зависимостью в веб-проектах. Эти типы следует разделять

Насколько я могу судить, это было вызвано # 32843, выпущенным как 4.1.9 . Этот комментарий подтверждает это.

Я опубликовал в этой ветке комментарий, касающийся этой проблемы.

/ cc @minestarks

исправление версии до 4.1.8 сработало для меня

Есть ли здесь PR, который решает эту проблему? Странно, что вы не можете использовать стилизованные компоненты в веб-проектах.

Получил ту же проблему, действительно, это около @types/styled-component .

my-app git:(master) ✗ npm ls @types/react-native
[email protected] /Users/devniel/dev/electron/my-app
└─┬ @types/[email protected]
  └── @types/[email protected]

Есть какие-нибудь обновления по проблеме?

Создайте файл .yarnclean со следующим содержимым:

@types/react-native

устраняет проблему 🎉

Полгода, а обновлений по этому поводу нет?

Неужели нет обновления ???

На мой взгляд, лучшим решением было бы сделать @ types / react-native зависимостью от одноранговых узлов, но, насколько мне известно, types-publisher в настоящий момент не поддерживает их. Может ли кто-нибудь из сопровождающих подтвердить, что я действительно прав и peerDep - это решение? Возможно, я смогу потратить некоторое время на выходные, добавив поддержку peerDep для types-publisher, если мы будем готовы.

Я считаю, что лучшим решением было бы сделать @ types / react-native зависимостью от однорангового узла.

Хм, если @types/react-native - одноранговый dep, мне нужно было бы объявить его как зависимость, чтобы использовать @types/styled-components в проекте, отличном от React Native. Это не идеально.

В идеале @types/react-native не потребуется для проекта, не относящегося к React Native; и особенно мне не нужно объявлять это как зависимость.

Вы хотите сделать это необязательной зависимостью?

@paulmelnikow , да, ты прав, я их перепутал. Вам все равно не нужно объявлять @types/react-native как зависимость, чтобы использовать @types/styled-components , но вы получите неприятное предупреждение, поэтому, конечно, optionalDeps - лучшее решение. types-publisher тоже не поддерживает, и я постараюсь разобраться в этом

Переход на "@ types / styled-components": "4.0.0" решил проблему.

Нет, это не решает. Подметает проблему под ковер

Нет, это не решает. Подметает проблему под ковер

Скажем, компилируется снова? ;-)

Создайте файл .yarnclean со следующим содержимым:

@types/react-native

устраняет проблему 🎉

Есть ли аналог с npm?

какой прогресс по этому вопросу?
это делает стилизованные компоненты непригодными для машинописного текста.

Погрузившись в реальный код этого репо, вы можете ясно увидеть, что @types/react-native требуется ТОЛЬКО в фактическом .d.ts и тестовом файле для интеграции React Native. Я думаю, что более подходящим решением было бы разделение всего, что связано с React Native, на его собственный подмодуль / необязательную / одноранговую зависимость, в соответствии с поведением того, как styled-components самом деле работает styled-components/native если вам нужен материал React Native. Вы не импортируете styled-components и получаете все джунгли React Native тоже во время выполнения, поэтому, импортировав всего styled-components я не должен также получить все джунгли @types/react-native типы.

Я думаю, что на данный момент интеграцию с response-native следует удалить из опубликованной NPM версии этого пакета и опубликовать как собственный пакет. В нынешнем виде это досадно сломано, и из-за этого TypeScript в целом выглядит плохо.

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

Погрузившись в реальный код этого репо, вы можете ясно увидеть, что @types/react-native требуется ТОЛЬКО в фактическом .d.ts и тестовом файле для интеграции React Native. Я думаю, что более подходящим решением было бы разделение всего, что связано с React Native, на его собственный подмодуль / необязательную / одноранговую зависимость, в соответствии с поведением того, как styled-components самом деле работает styled-components/native если вам нужен материал React Native. Вы не импортируете styled-components и получаете все джунгли React Native тоже во время выполнения, поэтому, импортировав всего styled-components я не должен также получить все джунгли @types/react-native типы.

👍

Я думаю, что на данный момент интеграцию с response-native следует удалить из опубликованной NPM версии этого пакета и опубликовать как собственный пакет.

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

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

ОпределенноTyped предоставляет отличную услугу сообществу пакетов, и здесь есть сопровождающие, но их задача не в том, чтобы поддерживать все типы. Встряхивание кулака в этом проекте (или в TypeScript) не поможет.

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

Как насчет того, чтобы мы просто отменили изменения, внесенные в # 32843, поскольку он нарушил типизацию примерно для> 90% пользователей и вынудил их использовать устаревшую версию или некоторые хаки, упомянутые в этой ветке.

Как насчет того, чтобы мы просто отменили изменения, внесенные в # 32843, поскольку он нарушил типизацию примерно для> 90% пользователей и вынудил их использовать устаревшую версию или некоторые хаки, упомянутые в этой ветке.

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

Я думаю, что если бы этот откат был сделан, это было бы добавление некоторых примечаний к пакету о том, как впоследствии заставить его работать с response-native. Я не пробовал это, но, вероятно, для пользователей, использующих реакцию, было бы возможно скопировать и вставить удаленные типы ввода в свой проект с объявлением declare module и все продолжит работать. Хотя, очевидно, стыдно заставлять пользователей, поддерживающих реакцию, делать это.

Хотя, честно говоря, мне бы очень хотелось, чтобы команда TypeScript могла предоставить какое-либо официальное руководство по решению подобных проблем, поскольку кажется, что кто-то в конечном итоге «проигрывает» во всех решениях.

ИМО, это должно быть отменено - в основном потому, что экосистема компонентов в веб-стиле больше.

Я больше не знаю всех деталей, как это работает, но раньше для React Native вы получали другой набор типов, используя другой путь, который казался мне хорошим компромиссом. Хм, похоже это то, что приносит. что обратно в это.

Интересно, может быть, есть способ иметь внешний модуль, который люди импортируют с помощью импорта с тройной косой чертой, который добавляет специфические для реакции типы?

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

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

Вот почему я умолял других разработчиков библиотек придерживаться своих типов. Это заставляет библиотеку обновлять свои типы. Мне нравится, что def typed во многом помог сообществу, но когда у сопровождающих lib есть возможность набирать его самостоятельно (или даже переписывать в ts), это делает мир более безопасным.

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

Есть ли какие-либо PR, ожидающие утверждения? Должен ли я внести одну строку изменения кода, которая удаляет недопустимую глобальную зависимость react-native (как я сделал это в моем частном репозитории npm)?

Кроме того, есть ли причина, по которой react-native должен быть установлен и конфликтует с глобальными пространствами имен? Пожалуйста, присоединяйтесь и делитесь своими мыслями. (Но мне интересно, прочитали бы этот выпуск те люди, которые непреднамеренно нарушили нашу работу, поскольку они были бы настолько счастливы, насколько им следовало бы, не имея представления о нашем ущербе. Я не могу сказать, что я никогда не был на другом конце такого дела до.)

Более того, как другие пакеты решают такие проблемы? Я понятия не имею об этом, так что не решаюсь сделать _ "простой" _ PR, который решит эту проблему.

Хотя я считаю, что это изменение следует отменить, нам не нужно было включать skipLibCheck чтобы эта работа работала: https://github.com/DefinitiTyped/DefinentyTyped/issues/33311#issuecomment -466731156. Пожалуйста, не надо.

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

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

какие-нибудь обновления по этому поводу?

@dawick люди, которым нужно печатать за react-native могут установить их вручную.
Зачем они вообще нужны?

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

Людям, которым нужен набор текста для react-native следует получить их, установив @types/react-native .

Я по-прежнему твердо придерживаюсь мнения, что все, что связано с react-native должно быть удалено из @types/styled-components и перемещено в другой пакет / путь, например, @types/styled-components/native чтобы соответствовать тому, как люди на самом деле используйте styled-components ; люди, которые хотят получить поддержку react-native явно получают ее, используя import styled from 'styled-components/native' , вы не получите всю react-native целиком, выполнив import styled from 'styled-components' в сети проект, поэтому связанные пакеты @types/ не должны вести себя иначе

На выходных я попытался исправить это более системным способом, что могло бы работать для любого репо, которое объединяет типы как для веб, так и для нативной реакции. https://github.com/microsoft/types-publisher/pull/655

как это не было решено ...

Шутки в сторону? По-прежнему нет исправления?

@givethemheller @ sanex3339 исправление находится в разработке и обсуждается на https://github.com/microsoft/types-publisher/pull/655

В качестве временного решения просто удалите @types/react-native из node_modules:
rm -rf node_modules/@types/react-native
и добавьте его в .yarnclean
@types/react-native

С выпуском TypeScript 3.7 мы теперь находимся в ситуации, когда пользователи 3.7 _ вынуждены_ обновлять свои определения типов, поскольку ранее работавшая v4.1.8 теперь несовместима с TS 3.7, но единственная версия, совместимая с TS 3.7, полностью сломана. для каждого React-веб-разработчика (а это, безусловно, подавляющее большинство). 😕

Обходной путь .yarnclean вероятно, будет достаточным для тех, кто использует Yarn, который включает меньше, чем все. А изменение compilerOptions - это вовсе не масштабируемое долгосрочное решение.

Я не знаю, какое здесь лучшее решение. В качестве временной меры я определенно выступаю за публикацию отдельной версии, которая специально исключает вещи react-native .

Как пользователь, не использующий пряжу, вы можете обойти это, добавив это в свои сценарии npm:

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

Заставит NPM удалить собственные типы сразу после их установки. Все еще хакерский обходной путь для того, что даже не должно быть проблемой, но оно работает.

Я тоже добавляюсь сюда. Нам нужно решение, лучше, чем редактирование множества сценариев после установки ...

Эта проблема затрагивает практически всех машинописных пользователей стилизованных компонентов более года (!!!).
Есть ли у нас какое-нибудь официальное решение для этого (не считая взломов с .yarnclean)? Есть ли блокираторы?

Я чувствую, что разделил бы это на два пакета (или потенциально на три, базовый один с общими вещами как для react-native, так и для react, один для реакции, а другой для RN, и заставить два последних использовать первый с общими вещами) быть самым простым и быстрым способом справиться с этим.

Я более чем готов помочь, если нам не хватает только участников, я просто хочу, чтобы было проще использовать как стилизованные компоненты, так и машинописный текст вместе, без необходимости взламывать что-то вокруг 😄

Я просто хочу, чтобы было проще использовать как стилизованные компоненты, так и машинописный текст вместе, без необходимости взламывать что-то вокруг 😄

Удар! Должна быть лучшая реализация определения типа ...

Я удалил @types/react-native из моих node_modules и все еще получаю ту же ошибку. Почему даже с взломом?

@ArnaudJeannin, если вы вручную удалили его вручную, он будет добавляться каждый раз, когда вы запускаете npm i / yarn

Чтобы сделать удаление постоянным при установке, либо удалите его через NPM postinstall в соответствии с моим предыдущим комментарием, либо добавьте его в .yarnclean если вы используете Yarn, должно работать нормально.

То, что я сделал, подойдет не всем, но я «решил» эту проблему, переключившись со стилизованных компонентов на эмоции . Я использую обе библиотеки довольно просто - просто обертываю компоненты с помощью CSS и наследую стили, но я обнаружил, что Emotion имеет аналогичный API для стилизованных компонентов для необходимых мне функций. Это был легкий переход. По прошествии 6 месяцев я не столкнулся с какими-либо серьезными проблемами. Emotion включает встроенные типы TS, поэтому нет проблем с рассинхронизацией с @types .

Как отмечалось выше, переключение библиотек CSS не будет подходящим для многих проектов, но для меня переключение было проще, чем спорить с проблемами TS со стилизованными компонентами. YMMV.

Более простой обходной путь для пользователей yarn , который позволит вам использовать текущую версию стилизованных компонентов. В package.json:

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

Настройте бездействующий пакет, который является целью разрешения выше:

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

Работает для меня.

@arimah @GabrielDuarteM , ты можешь объяснить свой голос против? Вы пробовали это и обнаружили, что это не работает? Пожалуйста, прокомментируйте, чтобы я мог помочь, и другие могли бы выиграть, если это так. Это кажется намного менее инвазивным, чем единственный другой обходной путь, доступный на данный момент (сценарий после установки для удаления модуля типа). Или, если в этом обходном пути есть какие-то сильные отрицательные стороны, которых я не осознал, я бы хотел изменить или удалить комментарий.

@jamietre Я считаю, что отрицательные голоса заключаются в том, что, хотя это может сработать, это неправильное решение и не меняет того факта, что типы должны быть разделены (или, возможно, взаимозависимости) для реагирования

@jamietre Я считаю, что отрицательные голоса заключаются в том, что, хотя это может сработать, это неправильное решение и не меняет того факта, что типы должны быть разделены (или, возможно, взаимозависимости) для реагирования

Не понимал, что обходные пути не одобряются. Я всегда нахожу их очень полезными в ожидании настоящего исправления. Это проблема уже больше года. и работа еще предстоит сделать. 🤷‍♂

@jamietre Я думаю, это просто то, что вы сформулировали это как «решение», а это не так, и создание его как такового может дать разработчикам представление о том, что это еще не нелепая проблема, затрагивающая большинство их пользователей.

@jamietre Я думаю, это просто то, что вы сформулировали это как «решение», а это не так, и создание его как такового может дать разработчикам представление о том, что это еще не нелепая проблема, затрагивающая большинство их пользователей.

Изменил «решение» на «обходной путь» ... на самом деле я просто пытаюсь помочь людям использовать стилизованные компоненты с машинописным текстом. Голос против означает, что это не работает. Спорить о семантике бесполезно, но я уверен.

В Appsome Solutions у нас была та же проблема, и мы решили ее с помощью правила "skipLibCheck": true, в файле tsconfig.json.

@pumanitro Как и многие другие предложения, это, к сожалению, не решение, а всего лишь обходной путь.

@SamHH Изменено слово решено на
Вот как это делается в CRA с машинописным текстом, но вы правы, это не решение. Тем не менее, это может помочь людям.

Повторная публикация моего комментария с https://github.com/DefinitiTyped/DefinitiTyped/pull/32843#issuecomment -605921101

Обходной путь состоит в том, чтобы иметь в вашем tsconfig.json compilerOptions.types массив tsconfig.json который не позволяет машинописному тексту автоматически читать каждый пакет @types/* при проверке типов. Typescript будет автоматически импортировать только те типы пакетов, которые указаны в массиве types ; например, "types": ["node"] (если вы используете встроенные модули, такие как buffer или path , для загрузки @types/node ), "types": ["node", "jest"] (если вы ' re также написание тестов на шутку); или даже просто "types": [] чтобы предотвратить автоматическую загрузку машинописного текста любого пакета, который не импортирован напрямую, или /// <reference types="..." /> из вашего кода.

Я не могу сказать, будет ли лучше иметь @types/styled-components-native ; это было бы как минимум необычно и, возможно, устранит необходимость в compilerOptions.types "обходном пути", но ИМО устанавливает compilerOptions.types только для пакетов, типы которых вам нужно загрузить автоматически (без import s) - лучшая практика.

Подводя итог, проблема в том, что TypeScript автоматически загружает типы @types/react-native , несмотря на то, что вы вообще не ссылаетесь на них прямо или косвенно, потому что по умолчанию загружаются все пакеты @types/* . Установка compilerOptions.types предотвращает использование этого значения по умолчанию и загружает только перечисленные вами пакеты + пакеты, которые вы import .

Не могу поверить, что это все еще проблема! Пробежавшись по этой проблеме прошлым летом, я только что обновил пакет, потому что предполагал, что с тех пор это будет исправлено 😠

кто поддерживает @ types / styled-components? потому что нам нужен кто-то новый

Предложение @Jessidhia с compilerOptions.types сработало для меня. Большое спасибо! Я также считаю это лучшей практикой. До сих пор недостатков у меня не было. Я мог представить, что это быстрее.

@sbusch недостатком является то, что если вы используете compilerOptions.types все ваши набранные вами символы должны быть перечислены здесь, поскольку все, что не включено в этот список, будет исключено. Итак, для установленных пакетов, которые предоставляют типизацию, вам нужно будет управлять этой конфигурацией вручную.

Да, перечислять все типы в типах - это не вариант.

Если вы импортируете что-то из модулей, вы все равно получаете типизацию TypeScript. Параметр types предназначен для автоматического импорта типов для глобальных объявлений. Это не требуется очень часто, поэтому неплохо было бы вручную добавить эти модули в types . Вот как я это понимаю. Наша довольно большая кодовая база TS с очень строгими настройками TS все еще работала после установки types array в [] .

См., Например, https://stackoverflow.com/a/59030291

недостатком является то, что если вы используете compilerOptions.types все ваши набранные вами символы должны быть перечислены здесь, поскольку все, что не включено в этот список, будет исключено. Итак, для установленных пакетов, которые предоставляют типизацию, вам нужно будет управлять этой конфигурацией вручную.

Как сказал @sbush , это неправда. Эта опция предназначена только для глобальных типов, типизация import ed libs будет использоваться без проблем. Предложение @Jessidhia безвредно.

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

Не уверен, что кто-то уже ответил на случай, когда у вас моно-репо Lerna + yarn workspaces (слишком много ответов). В этом случае вы можете использовать свойство no-hoist more info на веб-сайте yarn.

на практике в вашем package.json файле:

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

🙏🏻 @types/styled-components": "4.1.8" 🙏🏻

Решение, предлагаемое @nahumzs, работает, если вы используете пряжу monorepos. В этом случае мы предотвращаем загрязнение глобальной папки node_packages с помощью react-native, предотвращая дублирование, которое, в свою очередь, вызывает ошибки.

В какой момент мы просто скажем, что пользователей React Web больше, чем пользователей React Native, и лишим поддержки React Native?

Есть ли прогресс в этом вопросе? В настоящее время мы используем @ types / styled-components версию 4.1.8, потому что мы не можем выполнить обновление без разрешения или использования обходного решения, например, удаления node_modules / @ types / response-native в команде после установки npm.

Черт возьми, эта проблема причиняет мне действительно много боли.

Теперь я беру на себя проблему, описанную здесь . Итак, если я перейду на более новый Typescript, я даже не смогу использовать @types/[email protected] . 😡😡😡 WTH.

Во всяком случае, это похоже на дубликат https://github.com/DefinitiTyped/DefinentyTyped/issues/33015.

В Appsome Solutions у нас была та же проблема, и мы решили ее с помощью правила "skipLibCheck": true, в файле tsconfig.json.

На случай, если кто-то почувствовал то же самое: я не хотел включать skipLibCheck только для решения этой проблемы. Но теперь я передумал, потому что недавнее изменение включило skipLibCheck для новых проектов TypeScript - очевидно, из соображений производительности, но, возможно, и из-за проблем, подобных той, которую мы здесь видим.

может кто-то согласен с очень грязным хаком, вы можете просто добавить в свой package.json раздел скрипта:

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

Не лучшее решение, но это должно сработать.

OMG, эта проблема актуальна даже для 5.1.1

1- Добавьте .yarnclean в корень проекта.
2- Вставьте следующий контент: @types/react-native .

Здесь это решено, по крайней мере, пока я жду официального решения.

Это продолжается уже более полутора лет. В любом случае, я думаю, что моя проблема связана с этой проблемой, и я получаю намного больше ошибок типа «Повторяющиеся идентификаторы». Всего 36.

tsconfig.json

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

Результат компиляции с помощью tsc :

Итого: 38 ошибок. Только 2 из них взяты из моего фактического источника проекта src/**.* files. Остальные 36 ошибок связаны с конфликтами .d.ts вызванными @types/styled-components .

Примечание. Если я добавлю флаг "skipLibCheck": true , ошибки исчезнут. Также, если я удалю @types/styled-components , ошибки тоже исчезнут.

Я не буду публиковать здесь полный журнал, но вот несколько примеров.

error TS2300: Duplicate identifier 'AbortController'.
../../../AppData/Roaming/npm/node_modules/typescript/lib/lib.dom.d.ts:1939:11
../../../AppData/Roaming/npm/node_modules/typescript/lib/lib.dom.d.ts:1950:13 
node_modules/@types/react-native/globals.d.ts:363:15

error TS2300: Duplicate identifier 'AbortSignal'. 
../../../AppData/Roaming/npm/node_modules/typescript/lib/lib.dom.d.ts:1960:11 
node_modules/@types/react-native/globals.d.ts:350:15
../../../AppData/Roaming/npm/node_modules/typescript/lib/lib.dom.d.ts:1972:13

error TS2300: Duplicate identifier 'FormData'. 
../../../AppData/Roaming/npm/node_modules/typescript/lib/lib.dom.d.ts:5548:11
node_modules/@types/react-native/globals.d.ts:40:15
../../../AppData/Roaming/npm/node_modules/typescript/lib/lib.dom.d.ts:5558:13

error TS2300: Duplicate identifier 'URL'.
error TS2300: Duplicate identifier 'URLSearchParams'.
error TS2300: Duplicate identifier 'RequestInfo'.
error TS2300: Duplicate identifier 'XMLHttpRequestResponseType'.

error TS2717: Subsequent property declarations must have the same type.  Property 'body' 
must be of type 'string | ArrayBuffer | ArrayBufferView | Blob | FormData | URLSearchParams | ReadableStream<Uint8Array> | null | undefined', 
but here has type 'string | ArrayBuffer | DataView | Int8Array | Uint8Array | Uint8ClampedArray | Int16Array | ... 8 more ... | undefined'. 

error TS2717: Subsequent property declarations must have the same type.  Property 'signal' must be of type 'AbortSignal | null | undefined', but here has type 'AbortSignal | undefined'.

error TS2300: Duplicate identifier 'RequestInfo'.

На данный момент я принимаю решение: удалить @types/styled-components и продолжить работу над своим проектом (который является веб-приложением React).