Definitelytyped: node_modules/@types/react-native/globals.d.ts (36,15): Identificador duplicado 'FormData'.

Aquí igual

¿Por qué se agregó @ types / react-native? Tengo un proyecto web de reacción, ¿por qué tengo que instalar mecanografía que no uso?

Corregido por set compilerOptions.types manualmente

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

Yo también tengo el mismo problema.

El mismo problema aquí.
Como tengo varias definiciones de tipo en mi proyecto, configuré la dependencia @types/styled-components de una versión anterior.

Creo que agregar tipos explícitamente a tsconfig.json es una mala solución.
Sería mejor separar los tipos de styled-components para web y para nativo.

Tengo un problema con este FormData, estoy usando typescript: 3.3.333 aquí está mi package.json y tsconfig.json

PAQUETE 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" ] }

Tengo el mismo problema. Afortunadamente, pude solucionar el problema bloqueando la versión de @types/styled-components en 4.1.8

Lo mismo aquí, tuve que revertir a una versión anterior o agregar un script postinstall para eliminar react-native de node_modules

¿Cómo se supone que debes usar componentes con estilo en la web si sus dependencias chocan de forma predeterminada con las bibliotecas dom?
¡Esto es una locura!

Tengo el mismo problema y también noté que no todos los autores fueron notificados. Faltan estos dos: @ eps1lon @flavordaaave

@ArthurBrito gracias, se actualizó la lista de autores.

Este problema también me está sucediendo. @ types / react-native no debería ser una dependencia en proyectos web. Estos tipos deben estar separados

Por lo que puedo decir, esto fue causado por # 32843 que fue lanzado como 4.1.9 . Este comentario respalda eso.

Publiqué un comentario en ese hilo haciendo referencia a este problema.

/ cc @minestarks

arreglar la versión a 4.1.8 funcionó para mí

¿Hay un PR aquí que aborde este problema? Es extraño que no puedas usar componentes con estilo en proyectos web.

Tengo el mismo problema, de hecho se trata de @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]

¿Alguna actualización del problema?

Cree un archivo .yarnclean con el siguiente contenido:

@types/react-native

soluciona el problema 🎉

¿Medio año y todavía no hay actualizaciones para este problema?

Realmente no hay actualización ???

En mi opinión, la mejor solución sería hacer que @ types / react-native sea una dependencia entre pares, pero que yo sepa, types-publisher no los admite en este momento. ¿Puede alguno de los mantenedores verificar que de hecho estoy en lo cierto y que peerDep es una solución? Es posible que pueda dedicar un tiempo el fin de semana a agregar soporte peerDep a types-publisher, si estamos listos para comenzar.

En mi opinión, la mejor solución sería hacer que @ types / react-native sea una dependencia entre pares

Mmmm, si @types/react-native es un departamento de pares, necesitaría declararlo como una dependencia para poder usar @types/styled-components en un proyecto que no sea React Native. Eso no es ideal.

Idealmente, @types/react-native no sería requerido por un proyecto que no sea React Native; y especialmente no debería tener que _declararlo_ como una dependencia.

¿Quiere convertirlo en una dependencia opcional?

@paulmelnikow , sí, tienes razón, los he confundido. Aún no necesitaría declarar @types/react-native como una dependencia para usar @types/styled-components , pero recibirá una advertencia molesta, por lo que OptionalDeps es una mejor solución, por supuesto. types-publisher no los admite también, e intentaré investigarlo

Cambiar a "@ types / styled-components": "4.0.0" resolvió el problema.

No, no resuelve. Barre el problema debajo de la alfombra.

No, no resuelve. Barre el problema debajo de la alfombra.

¿Digamos que compila de nuevo? ;-)

Cree un archivo .yarnclean con el siguiente contenido:

@types/react-native

soluciona el problema 🎉

¿Existe algún equivalente con npm?

¿Algún progreso en este tema?
hace que los componentes con estilo sean inutilizables con mecanografiado.

Al sumergirse en el código real de este repositorio, puede ver claramente que @types/react-native SOLO se necesita en el archivo de prueba y .d.ts real para la integración de React Native. Creo que una solución más apropiada sería que cualquier cosa relacionada con React Native se divida en su propio submódulo / opcional / dependencia de pares, de acuerdo con el comportamiento de cómo funciona realmente styled-components , importa styled-components/native si quieres las cosas de React Native. No importa styled-components y obtiene toda la jungla de cosas de React Native también en tiempo de ejecución, por lo que al importar solo styled-components no debería obtener también toda la jungla de @types/react-native tipos.

Creo que, mientras tanto, la integración de react-native debería eliminarse de la versión publicada de NPM de este paquete y publicarse como su propio paquete. Tal como está, esto está avergonzadamente roto y hace que TypeScript en general se vea mal

Solucione este problema. Elimine los tipos nativos lo antes posible. Esto hace que lo que es un excelente proyecto de mecanografía sea casi inutilizable.

Al sumergirse en el código real de este repositorio, puede ver claramente que @types/react-native SOLO se necesita en el archivo de prueba y .d.ts real para la integración de React Native. Creo que una solución más apropiada sería que cualquier cosa relacionada con React Native se divida en su propio submódulo / opcional / dependencia de pares, de acuerdo con el comportamiento de cómo funciona realmente styled-components , importa styled-components/native si quieres las cosas de React Native. No importa styled-components y obtiene toda la jungla de cosas de React Native también en tiempo de ejecución, por lo que al importar solo styled-components no debería obtener también toda la jungla de @types/react-native tipos.

👍

Creo que, mientras tanto, la integración de react-native debería eliminarse de la versión publicada de NPM de este paquete y publicarse como su propio paquete.

Creo que podría ser una solución, aunque también me pregunto si podría haber una manera de enviarlos a ambos en el mismo paquete, como fue el impulso de # 32843, sin causar este problema.

Solo una nota amistosa para decir que la mejor manera de arreglar esto es profundizar y abrir un PR con una solución, o encontrar a alguien que haya invertido específicamente en Componentes con Estilo que pueda arreglarlo.

DefinitelyTyped brinda un servicio increíble a la comunidad de paquetes y hay mantenedores aquí, aunque su trabajo no es mantener todos los tipos. Sacudir el puño en este proyecto (o en TypeScript) no ayudará.

Estoy cambiando a la emoción
Incluyen sus propias definiciones mecanografiadas y tienen exactamente la misma interfaz, por lo que la migración es fácil de encontrar y reemplazar.
Además, el tamaño del paquete es un poco más pequeño.

¿Qué tal si revertimos los cambios introducidos en # 32843, ya que rompió los mecanografiados para como> 90% de los usuarios y los obligó a usar una versión desactualizada o algunos trucos mencionados en este hilo?

¿Qué tal si revertimos los cambios introducidos en # 32843, ya que rompió los mecanografiados para como> 90% de los usuarios y los obligó a usar una versión desactualizada o algunos trucos mencionados en este hilo?

Esa podría ser una solución razonable si hace que la mecanografía funcione mejor para la gran mayoría de usuarios. No sé con certeza si el PR se aprobaría o no, pero si cree que es la mejor solución, no dude en hacer un PR.

Creo que si se hiciera esta reversión, sería agregar algunas notas al paquete sobre cómo hacer que funcione con react-native después. No lo he probado, pero probablemente los usuarios nativos de reacción podrían copiar y pegar las mecanografías eliminadas en su proyecto con una declaración declare module y hacer que las cosas sigan funcionando. Aunque, obviamente, es una pena tener que hacer que los usuarios nativos de reacción hagan esto.

Aunque tbh, me encantaría si el equipo de TypeScript pudiera proporcionar alguna orientación oficial sobre cómo manejar problemas como estos, ya que parece que alguien termina "perdiendo" en todas las soluciones.

En mi opinión, esto debería revertirse, principalmente porque el ecosistema de componentes de estilo web es más grande.

Ya no conozco todos los detalles de cómo funciona, pero solía ser que para React Native obtendría un conjunto diferente de tipos usando una ruta diferente que me pareció un buen compromiso. Hrm, parece que esto es lo que trae. eso de nuevo en él.

Me pregunto si tal vez podría haber una manera de tener un módulo ambiental que la gente importe a través de una importación de triple barra que agregue los tipos específicos de react-native.

+1 aquí, pero no solo quejándome, si hay un plan de acción, quiero participar y ayudar a resolver este problema.

Vine aquí, fui a agregar mi más uno a algunos de los comentarios. Me di cuenta de que ya lo había hecho ... la última vez que encontré este problema.

Y es por eso que le he rogado a otros mantenedores de bibliotecas que mantengan sus tipos. Obliga a la biblioteca a actualizarse en línea con sus tipos. Me encanta que def typed haya ayudado a la comunidad de muchas maneras, pero cuando los mantenedores de lib tienen la capacidad de escribirlo ellos mismos (o incluso reescribirlo), se convierte en un mundo más seguro.

También me mantuve tranquilo y calmado sobre este problema, ya que pude solucionar este problema a través de un clon local, pero creo que la gente de todo el mundo había sufrido lo suficiente por este problema (más de 6 meses). Quiero que se solucione este problema crítico y paralizante, y permitir que los usuarios de mecanografiado no expertos en tecnología vuelvan a entrar.

¿Hay algún RP que esté pendiente de aprobación? ¿Debo poner una sola línea de cambio de código que elimine la dependencia global react-native no válida (como hice dentro de mi repositorio npm privado)?

Además, ¿hay alguna razón por la que react-native debería instalarse y entrar en conflicto con los espacios de nombres globales? Por favor intervenga y comparta sus pensamientos. (Pero me pregunto si esas personas que sin querer rompieron nuestro trabajo alguna vez leerían este número, ya que serían tan felices como deberían no tener ni idea de nuestro daño. No puedo decir que nunca estuve al otro lado de ese caso. antes de.)

Además, ¿cómo tratan otros paquetes este tipo de problemas? No tengo ni idea al respecto, por lo que estoy un poco indeciso en hacer un RP _ "simple" _ que revierte este problema.

Si bien creo que este cambio debería revertirse, no tuvimos necesidad de habilitar skipLibCheck para que esto funcione: https://github.com/DefinitelyTyped/DefinitelyTyped/issues/33311#issuecomment -466731156. Por favor no lo hagas.

No creo que revertir este cambio sea una buena opción. Mucha gente necesita tipificaciones para react-native y deberíamos arreglar lo que causa un error y no eliminar todas las tipificaciones de react-native.

¿Y si no hay solución por el momento? Deberíamos proporcionar al menos una versión para los usuarios no nativos, ya que está completamente rota en este momento y lo ha estado por un tiempo, y me atrevería a adivinar que los usuarios no nativos también son la mayoría.

alguna actualización sobre esto?

Las personas de react-native pueden instalarlos manualmente.
¿Por qué necesitaban en absoluto?

No creo que revertir este cambio sea una buena opción. Mucha gente necesita tipificaciones para react-native y deberíamos arreglar lo que causa un error y no eliminar todas las tipificaciones de react-native.

Las personas que necesitan mecanografiar por react-native deben obtenerlas instalando @types/react-native .

Todavía estoy firmemente en la posición de que todo lo relacionado con react-native debe eliminarse de @types/styled-components y trasladarse a un paquete / ruta diferente, por ejemplo, @types/styled-components/native para ser coherente con la forma en que las personas realmente use styled-components ; las personas que quieren react-native soporte explícitamente lo obtienen usando import styled from 'styled-components/native' , no obtienes la totalidad de la react-native jungle haciendo import styled from 'styled-components' en una web proyecto, por lo que los paquetes @types/ asociados no deberían comportarse de manera diferente

Intenté arreglar esto de una manera más sistémica durante el fin de semana, lo que podría funcionar para cualquier repositorio que envuelva tipos para web + react native. https://github.com/microsoft/types-publisher/pull/655

cómo no se ha abordado esto ...

¿Seriamente? ¿Aún no tienes solución?

@givethemheller @ sanex3339 hay una solución en proceso y discusión en https://github.com/microsoft/types-publisher/pull/655

Como solución temporal, simplemente elimine @types/react-native de node_modules:
rm -rf node_modules/@types/react-native
y agréguelo a .yarnclean
@types/react-native

Con el lanzamiento de TypeScript 3.7, ahora nos encontramos en una situación en la que los usuarios 3.7 se ven obligados a actualizar sus definiciones de tipo, ya que la v4.1.8 que funcionaba anteriormente ahora es incompatible con TS 3.7, pero la única versión compatible con TS 3.7 está completamente rota. para cada desarrollador de React-web (que seguramente debe ser la gran y abrumadora mayoría). 😕

La solución alternativa .yarnclean probablemente sea suficiente para aquellos que usan Yarn, que incluye menos que todos. Y modificar compilerOptions no es en absoluto una solución escalable a largo plazo.

No sé cuál es la mejor solución aquí. Como medida provisional, definitivamente estoy a favor de publicar una versión separada que excluya específicamente las cosas react-native .

Como usuario que no es hilo, puede solucionarlo agregando esto a sus scripts npm:

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

Hará que NPM elimine los tipos nativos inmediatamente después de instalarlos. Sigue siendo una solución hacky para lo que ni siquiera debería ser un problema, pero funciona.

Añadiéndome aquí también. Necesitamos una solución, mejor que editar muchos scripts posteriores a la instalación ...

Este problema está afectando básicamente a todos los usuarios de mecanografiado de componentes con estilo durante más de un año (!!!).
¿Tenemos alguna solución oficial para esto (sin contar los hacks con .yarnclean)? ¿Hay bloqueadores?

Tengo ganas de dividir esto en dos paquetes (o potencialmente tres, uno base con cosas comunes para react-native y react, uno para react y otro para RN, y hacer que los dos últimos usen el primero con las cosas comunes) sea ​​la forma más fácil y rápida de lidiar con eso.

Estoy más que dispuesto a ayudar, si solo nos faltan colaboradores, solo quiero que sea más fácil usar tanto los componentes con estilo como el mecanografiado juntos, sin tener que piratear cosas 😄

Solo quiero que sea más fácil usar tanto los componentes con estilo como el mecanografiado juntos, sin tener que hackear cosas 😄

¡Protuberancia! Debe haber una mejor implementación de la definición de tipo ...

Eliminé @types/react-native de mis node_modules y sigo recibiendo el mismo error. ¿Por qué incluso con el truco?

@ArnaudJeannin, si lo eliminó manualmente a mano, se volverá a agregar cada vez que ejecute npm i / yarn

Para que la eliminación sea persistente a través de las instalaciones, ya sea eliminándola a través de NPM postinstall según mi comentario anterior o agregándola a .yarnclean si usa Yarn debería funcionar bien.

Lo que hice no será apropiado para todos, pero "resolví" este problema cambiando de componentes de estilo a emoción . Mi uso de cualquiera de las bibliotecas es bastante básico, solo envolviendo componentes con CSS y heredando estilos, pero encontré que Emotion tiene una API similar a los componentes con estilo para las características que necesitaba. Fue una transición fácil. No me he encontrado con ningún problema importante hasta ahora después de 6 meses. Emotion incluye mecanografía TS incorporada, por lo que no hay problemas de desincronización con @types .

Como se señaló anteriormente, cambiar las bibliotecas CSS no será apropiado para muchos proyectos, pero para mí, cambiar fue más fácil que lidiar con problemas de TS de componentes con estilo. YMMV.

Solución alternativa más sencilla para los usuarios de yarn , que le permitirá utilizar la versión actual de los componentes con estilo. En package.json:

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

Configure un paquete sin hacer nada que sea el objetivo de la resolución anterior:

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

Funciona para mi.

@arimah @GabrielDuarteM , ¿puedes explicar tu voto negativo ? ¿Intentó esto y descubrió que no funcionó? Por favor comente para que pueda ayudar y para que otros puedan beneficiarse si es así. Esto parece mucho menos invasivo que la única otra solución alternativa disponible en este momento (un script posterior a la instalación para eliminar el módulo de tipo). O si hay algo muy negativo en esta solución alternativa que no me he dado cuenta, me gustaría revisar o eliminar el comentario.

@jamietre Creo que los

@jamietre Creo que los

No me di cuenta de que las soluciones alternativas estaban mal vistas. Siempre los encuentro muy útiles mientras espero una solución real. Este ha sido un problema durante más de un año. y aún queda trabajo por hacer. 🤷‍♂

@jamietre Creo que es solo que lo

@jamietre Creo que es solo que lo

Se cambió "solución" a "solución alternativa" ... en realidad, solo estoy tratando de ayudar a la gente a poder usar componentes con estilo con mecanografiado. Los votos negativos implican que no funciona. No parece útil discutir sobre semántica, pero seguro.

En Appsome Solutions tuvimos el mismo problema y lo solucionamos con la regla "skipLibCheck": true, en un archivo tsconfig.json.

@pumanitro Como se

@SamHH Se cambió la palabra resuelta a alternativa.
Así es como se hace en CRA con mecanografiado, pero tienes razón, no es una solución. Aún así, puede ayudar a la gente.

Volviendo a publicar mi comentario de https://github.com/DefinitelyTyped/DefinitelyTyped/pull/32843#issuecomment -605921101

La solución alternativa es tener una matriz compilerOptions.types en su tsconfig.json que impida que el mecanografiado lea automáticamente todos los paquetes @types/* al comprobar el tipo. Typecript solo importará automáticamente los tipos de paquetes nombrados en la matriz types ; por ejemplo, "types": ["node"] (si usa módulos integrados como buffer o path , para cargar @types/node ), "types": ["node", "jest"] (si ' también está escribiendo pruebas de broma); o incluso solo "types": [] para evitar que el mecanografiado cargue automáticamente cualquier paquete que no se importe directamente o /// <reference types="..." /> de su código.

Realmente no puedo decir si tener un @types/styled-components-native sería mejor; sería inusual por lo menos, y tal vez eliminaría la necesidad de la "solución alternativa" compilerOptions.types , pero IMO configurando compilerOptions.types solo para los paquetes cuyos tipos necesita cargar automáticamente (sin import s) es una buena práctica.

Para resumir, el problema es que TypeScript carga automáticamente los tipos @types/react-native , a pesar de que no los hace referencia directa o indirectamente, porque el comportamiento predeterminado es cargar todos los paquetes @types/* . Configurar compilerOptions.types evita ese valor predeterminado y carga solo los paquetes que enumera + los paquetes que import .

¡No puedo creer que esto siga siendo un problema! Me encontré con este problema el verano pasado, acabo de actualizar el paquete porque asumí que esto se habría solucionado desde entonces 😠

¿Quién es el responsable de mantenimiento de @ types / styled-components? porque necesitamos a alguien nuevo

La propuesta de @Jessidhia con compilerOptions.types funcionó para mí. ¡Muchos gracias! También veo esto como una mejor práctica. Hasta ahora no experimenté desventajas. Me imagino que también es más rápido.

@sbusch, la desventaja es que si usa compilerOptions.types todas sus mecanografías deberán incluirse aquí, ya que todo lo que no esté incluido en esta lista será excluido. Por lo tanto, para los paquetes que están instalados y proporcionan tipificaciones, deberá administrar esta configuración manualmente

Sí, enumerar todos los tipos en tipos no es una opción.

Si importa algo de un módulo, aún obtendrá las mecanografías de TypeScript. La opción types es para tipos de importación automática para las declaraciones globales. Esto no es necesario con mucha frecuencia, por lo que no debería ser tan malo agregar manualmente esos módulos a types . Así es como lo entiendo. Nuestra base de código TS bastante grande con configuraciones de TS muy estrictas todavía funcionaba después de configurar types array en [] .

Consulte, por ejemplo, https://stackoverflow.com/a/59030291

la desventaja es que si usa compilerOptions.types todas sus mecanografías deberán aparecer aquí, ya que todo lo que no esté incluido en esta lista será excluido. Por lo tanto, para los paquetes que están instalados y proporcionan tipificaciones, deberá administrar esta configuración manualmente

Como dijo @sbush , esto no es cierto. Esa opción es solo para tipos globales, las mecanografías de import ed libs se usarán sin problemas. La propuesta de @Jessidhia es inofensiva.

No creo que un solo paquete deba obligar a los consumidores a romper con la convención, que es dejar ese campo en paz. Como con todo lo demás, esa no es una solución, sino una solución alternativa.

No estoy seguro de si alguien ya respondió el caso cuando tiene un repositorio mono Lerna + yarn workspaces (demasiadas respuestas). Para este caso, puede hacer uso de la propiedad no-hoist más información en el sitio web de yarn

en prácticas en su archivo package.json :

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

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

La solución que propone @nahumzs funciona si está utilizando hilo monorepos. En este caso, evitamos que react-native contamine la carpeta global node_packages, evitando duplicados que a su vez arrojen errores.

¿En qué momento decimos que hay más usuarios de React Web que usuarios de React Native y eliminamos el soporte de React Native?

¿Ha habido algún progreso en este tema? Actualmente estamos en la versión 4.1.8 de @ types / styled-components porque no podemos actualizar sin una resolución o utilizar una solución alternativa, como eliminar node_modules / @ types / react-native en un comando npm posterior a la instalación.

Oh, carajo, este problema me causa mucho dolor.

Ahora estoy incurriendo en el problema que se describe aquí . Entonces, si actualizo a Typecript más nuevo, ni siquiera puedo usar @types/[email protected] . 😡😡😡 PESO.

De todos modos, esto parece ser un duplicado de https://github.com/DefinitelyTyped/DefinitelyTyped/issues/33015.

En Appsome Solutions tuvimos el mismo problema y lo solucionamos con la regla "skipLibCheck": true, en un archivo tsconfig.json.

En caso de que alguien sintiera lo mismo: no quería habilitar skipLibCheck solo para solucionar este problema. Pero cambié de opinión ahora que un cambio reciente habilitó skipLibCheck para proyectos nuevos de TypeScript , aparentemente por razones de rendimiento, pero podría imaginarlo también debido a problemas como el que estamos viendo aquí.

tal vez alguien esté bien con un truco muy sucio, puede agregarlo a la sección de su script package.json :

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

No es una gran solución, pero debería funcionar.

Dios mío, este problema sigue siendo real incluso para 5.1.1

1- Agrega un .yarnclean en la raíz del proyecto.
2- Inserta el siguiente contenido: @types/react-native .

Esto se resolvió aquí al menos mientras espero una solución oficial.

Esto ha estado sucediendo durante más de 1,5 años, ahora. De todos modos, creo que mi problema está relacionado y recibo muchos más errores de "Identificadores duplicados". 36 en total.

tsconfig.json

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

Resultado de compilar con tsc :

Total: 38 errores. Solo 2 de ellos son de mi fuente de proyecto real src/**.* archivos. Los otros 36 errores son de .d.ts conflictos causados ​​por @types/styled-components .

Nota: Si agrego la bandera "skipLibCheck": true , los errores desaparecen. Además, si elimino @types/styled-components , los errores también desaparecen.

No publicaré el registro completo aquí, pero aquí hay algunos ejemplos.

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'.

La solución que estoy adoptando en este momento es eliminar @types/styled-components y seguir adelante con mi proyecto (que es una aplicación web React).