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

Mesmo aqui

Por que @ types / react-native foi adicionado? Eu tenho um projeto da web react, por que tenho que instalar as tipificações que não uso?

Corrigido por set compilerOptions.types manualmente

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

Eu também tenho o mesmo problema.

O mesmo problema aqui.
Como tenho várias definições de tipo em meu projeto, fixei a dependência @types/styled-components em uma versão anterior.

Acho que adicionar tipos explicitamente a tsconfig.json é uma solução ruim.
Seria melhor separar os tipos para styled-components para web e para nativo.

Estou tendo um problema com este FormData, estou usando typescript: 3.3.333 aqui está meu package.json e tsconfig.json

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

Eu tenho o mesmo problema. Felizmente, consegui superar o problema bloqueando a versão de @types/styled-components para 4.1.8

O mesmo aqui, tive que reverter para uma versão anterior ou adicionar um script postinstall para remover react-native de node_modules

Como você pode usar componentes estilizados na web se suas dependências entram em conflito por padrão com as libs dom ?!
Isso é uma loucura!

Tenho o mesmo problema e também notei que nem todos os autores foram notificados. Esses dois estão faltando: @ eps1lon @flavordaaave

@ArthurBrito obrigado, lista de autores atualizada.

Este problema está acontecendo comigo também. @ types / react-native não deve ser uma dependência em projetos da web. Esses tipos devem ser separados

Pelo que eu posso dizer, isso foi causado por # 32843, que foi lançado como 4.1.9 . Este comentário confirma isso.

Eu postei um comentário naquele tópico fazendo referência a esse problema.

/ cc @minestarks

corrigir a versão 4.1.8 funcionou para mim

Existe um PR aqui que trata desse problema? Estranho, você não pode usar componentes estilizados em projetos da web.

Tenho o mesmo problema, na verdade é cerca 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]

Alguma atualização do problema?

Crie um arquivo .yarnclean com o seguinte conteúdo:

@types/react-native

corrige o problema 🎉

Meio ano e ainda sem atualizações para este problema?

Realmente sem atualização ???

Em minha opinião, a melhor solução seria tornar @ types / react-native uma dependência de peer, mas até onde sei types-publisher não oferece suporte para isso no momento. Um dos mantenedores pode verificar se estou de fato certo e se o peerDep é uma solução? Posso passar algum tempo no fim de semana adicionando suporte peerDep ao types-publisher, se estivermos prontos.

Na minha opinião, a melhor solução seria tornar @ types / react-native uma dependência de peer

Hmm, se @types/react-native for um peer dep, eu precisaria declará-lo como uma dependência para usar @types/styled-components em um projeto não React Native. Isso não é o ideal.

Idealmente, @types/react-native não seria exigido por um projeto não React Native; e eu, especialmente, não deveria ter que _declará-lo_ como uma dependência.

Você pretende torná-lo uma dependência opcional?

@paulmelnikow , sim, você está certo, eu confundi os dois. Você ainda não precisaria declarar @types/react-native como uma dependência para usar @types/styled-components , mas você receberá um aviso incômodo, então optionalDeps é uma solução melhor, é claro. types-publisher não os oferece suporte e vou tentar investigar isso

Fazer o downgrade para "@ types / styled-components": "4.0.0" resolveu o problema.

Não, não resolve. Ele varre o problema para debaixo do tapete

Não, não resolve. Ele varre o problema para debaixo do tapete

Digamos que ele compile novamente? ;-)

Crie um arquivo .yarnclean com o seguinte conteúdo:

@types/react-native

corrige o problema 🎉

Existe algum equivalente com npm?

algum progresso nesta questão?
torna os componentes estilizados inutilizáveis ​​com o texto datilografado.

Mergulhando no código real deste repo, você pode ver claramente que @types/react-native é SOMENTE necessário no .d.ts real e no arquivo de teste para a integração do React Native. Eu acho que uma solução mais apropriada seria para qualquer coisa relacionada ao React Native ser dividida em sua própria dependência de submódulo / opcional / par, consistente com o comportamento de como styled-components realmente funciona, você importa styled-components/native se você quiser o material do React Native. Você não importa styled-components e obtém toda a selva de coisas do React Native também em tempo de execução, portanto, importando apenas styled-components eu não deveria estar recebendo toda a selva de @types/react-native tipos.

Acho que, por enquanto, a integração reativa-nativa deve ser excluída da versão publicada do NPM deste pacote e publicada como seu próprio pacote. Do jeito que está, isso está embaraçosamente quebrado e faz com que o TypeScript como um todo pareça ruim

Por favor, corrija este problema. Retire os tipos nativos o mais rápido possível. Isso torna o que de outra forma seria um excelente projeto de digitação quase inutilizável.

Mergulhando no código real deste repo, você pode ver claramente que @types/react-native é SOMENTE necessário no .d.ts real e no arquivo de teste para a integração do React Native. Eu acho que uma solução mais apropriada seria para qualquer coisa relacionada ao React Native ser dividida em sua própria dependência de submódulo / opcional / par, consistente com o comportamento de como styled-components realmente funciona, você importa styled-components/native se você quiser o material do React Native. Você não importa styled-components e obtém toda a selva de coisas do React Native também em tempo de execução, portanto, importando apenas styled-components eu não deveria estar recebendo toda a selva de @types/react-native tipos.

👍

Acho que, por enquanto, a integração reativa-nativa deve ser excluída da versão publicada do NPM deste pacote e publicada como seu próprio pacote.

Eu acho que poderia ser uma solução, embora também me pergunto se haveria uma maneira de enviá-los no mesmo pacote, como foi o impulso do # 32843, sem causar esse problema.

Apenas uma nota amigável para dizer que a melhor maneira de consertar isso é cavar e abrir um PR com uma solução, ou encontrar alguém especificamente investido em componentes estilizados que possa consertar.

DefinitelyTyped fornece um serviço incrível para a comunidade de pacotes e há mantenedores aqui, embora seu trabalho não seja manter todos os tipos. Agitar seu punho neste projeto (ou no TypeScript) não vai ajudar.

Estou mudando para emoção
Eles incluem suas próprias definições de texto datilografado e têm exatamente a mesma interface, portanto, a migração é fácil de localizar e substituir.
Além disso, o tamanho do pacote é um pouco menor.

Que tal revertermos as alterações introduzidas em # 32843, uma vez que quebrou a digitação de cerca de 90% dos usuários e os forçou a usar uma versão desatualizada ou alguns hacks mencionados neste tópico.

Que tal revertermos as alterações introduzidas em # 32843, uma vez que quebrou a digitação de cerca de 90% dos usuários e os forçou a usar uma versão desatualizada ou alguns hacks mencionados neste tópico.

Essa poderia ser uma solução razoável se fizer com que a digitação funcione melhor para a grande maioria dos usuários. Não sei ao certo se o PR seria aprovado ou não, mas se você acha que é a melhor solução, fique à vontade para fazer um PR.

Eu acho que se essa reversão fosse feita, seria adicionar algumas notas ao pacote sobre como fazê-lo funcionar com o react-native depois. Eu não experimentei, mas provavelmente seria possível para os usuários do reagente nativo copiar e colar as digitações removidas em seus projetos com uma declaração declare module e fazer com que as coisas continuem funcionando. Embora obviamente seja uma pena ter que obrigar os usuários nativos a fazer isso.

Embora tbh, adoraria se a equipe do TypeScript pudesse fornecer alguma orientação oficial sobre como lidar com problemas como esses, já que parece que alguém acaba "perdendo" em todas as soluções.

IMO, isso deve ser revertido - principalmente porque o ecossistema de componentes de estilo web é maior.

Não sei mais todos os detalhes de como funciona, mas costumava ser que para React Native você obteria um conjunto diferente de tipos usando um caminho diferente que parecia ser um bom compromisso para mim. Hrm, parece que isso é o que traz. isso de volta para ele.

Eu me pergunto se talvez houvesse uma maneira de ter um módulo de ambiente que as pessoas importem por meio de uma importação de barra tripla que adiciona os tipos específicos de reagentes nativos?

+1 aqui, mas não só reclamando, se houver um plano de ação quero participar e ajudar a resolver esse problema.

Eu vim aqui, fui adicionar meu mais um a alguns dos comentários. Percebi que já tinha feito isso ... a última vez que encontrei esse problema.

E é por isso que implorei a outros mantenedores de bibliotecas que mantivessem seus tipos. Ele força a biblioteca a atualizar em linha com seus tipos. Eu adoro que def digitado tenha ajudado a comunidade de muitas maneiras, mas quando os mantenedores da lib têm a habilidade de digitar por conta própria (ou mesmo reescrever em ts), torna-se um mundo mais seguro.

Eu também estava relaxado e calmo com relação a esse problema, pois consegui contorná-lo por meio de um clone local, mas acho que as pessoas em todo o mundo já haviam sofrido o suficiente com esse problema (mais de 6 meses). Quero que esse problema crítico e incapacitante seja corrigido e permita que os usuários de digitação que não entendem de tecnologia voltem a agir.

Há algum PRs aguardando aprovação? Devo colocar uma única linha de alteração de código que remove react-native dependência global inválida (como fiz em meu repositório npm privado)?

Além disso, há uma razão para que react-native deva ser instalado e entrar em conflito com namespaces globais? Por favor, entre e compartilhe suas idéias. (Mas eu me pergunto se aquelas pessoas que involuntariamente quebraram nosso trabalho iriam ler esta edição, pois elas ficariam tão felizes quanto deveriam estar, não tendo idéia de nossos danos. Não posso dizer que nunca estive no outro lado do caso antes.)

Além disso, como outros pacotes lidam com esse tipo de problema? Eu não tenho ideia sobre isso, estou meio hesitante em fazer um _ "simples" _ PR que reverta este problema.

Embora eu ache que essa alteração deve ser revertida, não precisamos ativar skipLibCheck para fazer isso funcionar: https://github.com/DefinitelyTyped/DefinitelyTyped/issues/33311#issuecomment -466731156. Por favor, não faça isso.

Não acho que reverter essa mudança seja uma boa opção. Muitas pessoas precisam de tipagens para reagir nativo e devemos consertar o que causa um erro e não remover todas as tipificações react-nativas.

E se não houver solução no momento? Devemos fornecer pelo menos uma versão para usuários não nativos, já que ela está totalmente corrompida no momento e está há algum tempo, e eu me arrisco a adivinhar que os usuários não nativos também são a maioria.

alguma atualização sobre isso?

@dawick pessoas que precisam digitar react-native podem instalá-los manualmente.
Por que eles precisam, afinal?

Não acho que reverter essa mudança seja uma boa opção. Muitas pessoas precisam de tipagens para reagir nativo e devemos consertar o que causa um erro e não remover todas as tipificações react-nativas.

Pessoas que precisam de digitações para react-native devem obtê-las instalando @types/react-native .

Ainda estou fortemente de acordo com a posição de que tudo relacionado a react-native deve ser excluído de @types/styled-components e movido para um pacote / caminho diferente, por exemplo @types/styled-components/native para ser consistente com a forma como as pessoas realmente use styled-components ; pessoas que desejam react-native suporte explicitamente obtêm-no usando import styled from 'styled-components/native' , você não obtém toda a selva react-native fazendo import styled from 'styled-components' em uma web projeto, portanto, os pacotes @types/ associados não devem se comportar de maneira diferente

Tentei consertar isso de uma forma mais sistêmica no fim de semana, o que poderia funcionar para qualquer repo que envolva tipos para web + react nativos. https://github.com/microsoft/types-publisher/pull/655

como isso não foi resolvido ...

Seriamente? Ainda sem conserto?

@givethemheller @ sanex3339 há uma correção em andamento e discussão em https://github.com/microsoft/types-publisher/pull/655

Como solução temporária, basta remover @types/react-native de node_modules:
rm -rf node_modules/@types/react-native
e adicione-o a .yarnclean
@types/react-native

Com o lançamento do TypeScript 3.7, agora nos encontramos em uma situação em que os usuários do 3.7 são _forçados_ a atualizar suas definições de tipo, já que a v4.1.8 que funcionava anteriormente agora é incompatível com o TS 3.7, mas a única versão compatível com o TS 3.7 está totalmente quebrada para cada desenvolvedor React-web (que certamente deve ser a vasta e esmagadora maioria). 😕

A solução alternativa .yarnclean provavelmente é suficiente para aqueles que usam o Yarn, que inclui menos do que todos. E modificar compilerOptions não é uma solução escalonável de longo prazo.

Não sei qual é a melhor solução aqui. Como paliativo, sou definitivamente a favor da publicação de uma versão separada que exclua especificamente as react-native coisas.

Como um usuário que não é do yarn, você pode contornar isso adicionando aos seus scripts npm:

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

Fará com que o NPM exclua os tipos nativos imediatamente após instalá-los. Ainda é uma solução alternativa para o que nem deveria ser um problema, mas funciona.

Adicionando-me aqui também. Precisamos de uma solução, melhor do que editar muitos scripts pós-instalação ...

Esse problema está afetando basicamente todos os usuários de datilografia de componentes estilizados por mais de um ano (!!!).
Temos alguma solução oficial para isso (sem contar os hacks com .yarnclean)? Existem bloqueadores?

Eu sinto que dividir isso em dois pacotes (ou potencialmente três, um básico com coisas comuns para react-native e react, um para react e outro para RN, e fazer os dois últimos usarem o primeiro com as coisas comuns) ser a maneira mais fácil e rápida de lidar com isso.

Estou mais do que disposto a ajudar, se faltam apenas contribuidores, só quero que seja mais fácil usar os componentes estilizados e o texto datilografado juntos, sem ter que hackear coisas 😄

Eu só quero que seja mais fácil usar os componentes estilizados e o texto datilografado juntos, sem ter que hackear coisas 😄

Ressalto! Deve haver uma implementação de definição de tipo melhor ...

Removi @types/react-native de meus node_modules e continuo recebendo o mesmo erro. Por que mesmo com o hack?

@ArnaudJeannin se você o excluiu manualmente, ele será adicionado de volta toda vez que você executar npm i / yarn

Para tornar a exclusão persistente por meio de instalações, removê-lo via NPM postinstall acordo com meu comentário anterior ou adicioná-lo a .yarnclean se você usar o Yarn deve funcionar bem.

O que eu fiz não será apropriado para todos, mas eu "resolvi" esse problema mudando de componentes estilizados para emoção . Meu uso de qualquer uma das bibliotecas é bem básico - apenas agrupando componentes com CSS e estilos herdados - mas descobri que o Emotion tem uma API semelhante a componentes com estilo para os recursos que eu precisava. Foi uma transição fácil. Não encontrei nenhum problema significativo até agora, após 6 meses. O Emotion inclui tipificações TS integradas para que não haja problemas de fora de sincronia com @types .

Conforme observado acima, trocar bibliotecas CSS não será apropriado para muitos projetos, mas para mim trocar foi mais fácil do que lidar com problemas de TS de componentes estilizados. YMMV.

Solução alternativa mais simples para yarn usuários, que permitirá que você use a versão atual de componentes estilizados. Em package.json:

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

Configure um pacote de não fazer nada que seja o alvo da resolução acima:

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

Funciona para mim.

@arimah @GabrielDuarteM , você pode explicar seu voto negativo ? Você tentou fazer isso e não funcionou? Por favor, comente para que eu possa ajudar e para que outros possam se beneficiar. Isso parece muito menos invasivo do que a única outra solução alternativa disponível neste ponto (um script de pós-instalação para excluir o módulo de tipo). Ou se houver algum forte negativo nesta solução alternativa que eu não percebi, gostaria de revisar ou remover o comentário.

@jamietre Eu acredito que os

@jamietre Eu acredito que os

Não percebi que as soluções alternativas eram desaprovadas. Sempre os considero muito úteis enquanto espero por uma solução real. Isso tem sido um problema há mais de um ano. e o trabalho ainda precisa ser feito. 🤷‍♂

@jamietre Eu acho que você apenas o enquadrou como uma "solução", o que não é, e enquadrá-lo como tal pode dar aos mantenedores a ideia de que este não é um problema ridículo afetando a maioria de seus usuários.

@jamietre Eu acho que você apenas o enquadrou como uma "solução", o que não é, e enquadrá-lo como tal pode dar aos mantenedores a ideia de que este não é um problema ridículo afetando a maioria de seus usuários.

Alterei "solução" para "solução alternativa" ... na verdade, estou apenas tentando ajudar as pessoas a usarem componentes estilizados com texto datilografado. Os votos negativos indicam que não funciona. Não parece útil discutir sobre a semântica, mas com certeza.

No Appsome Solutions , tivemos o mesmo problema e o resolvemos com a regra "skipLibCheck": true, em um arquivo tsconfig.json.

@pumanitro Como muitas outras coisas sugeridas, isso infelizmente não é uma solução, mas uma mera solução alternativa.

@SamHH Palavra alterada resolvida para alternativa.
É assim que é feito no CRA com texto datilografado, mas você está certo, não é uma solução. Ainda assim, pode ajudar as pessoas.

Repostagem de meu comentário de https://github.com/DefinitelyTyped/DefinitelyTyped/pull/32843#issuecomment -605921101

A solução alternativa é ter um array compilerOptions.types em seu tsconfig.json que impeça o texto datilografado de ler automaticamente cada pacote @types/* durante a verificação de digitação. O texto de tipo importará automaticamente apenas os tipos de pacotes nomeados no array types ; por exemplo, "types": ["node"] (se você usar módulos embutidos como buffer ou path , para carregar @types/node ), "types": ["node", "jest"] (se você ' também estou escrevendo testes de brincadeira); ou mesmo apenas "types": [] para evitar que o texto digitalizado carregue automaticamente qualquer pacote que não seja diretamente importado ou /// <reference types="..." /> do seu código.

Eu realmente não posso dizer se ter um @types/styled-components-native seria melhor; seria no mínimo incomum, e talvez remova a necessidade da "solução alternativa" compilerOptions.types , mas IMO definindo compilerOptions.types apenas para os pacotes cujos tipos você precisa ser carregado automaticamente (sem import s) é uma prática recomendada.

Para resumir, o problema é que o TypeScript está carregando automaticamente os tipos @types/react-native , apesar de você não referenciá-los direta ou indiretamente, porque o comportamento padrão é carregar todos os pacotes @types/* . Definir compilerOptions.types evita esse padrão e carrega apenas os pacotes que você listar + os pacotes que você import .

Eu não posso acreditar que isso ainda é um problema! Tive esse problema no verão passado, acabei de atualizar o pacote porque presumi que isso teria sido corrigido desde então 😠

quem é o mantenedor dos @ types / styled-components? porque precisamos de alguém novo

A proposta da @Jessidhia com compilerOptions.types funcionou para mim. Muito obrigado! Eu também vejo isso como uma prática recomendada. Até agora não experimentei desvantagens. Eu poderia imaginar que também é mais rápido.

@sbusch a desvantagem é que se você usar compilerOptions.types todas as suas digitações precisarão ser listadas aqui, pois qualquer coisa não incluída nesta lista será excluída. Então, para os pacotes instalados que fornecem tipificações, você precisará gerenciar esta configuração manualmente

Sim, listar todos os tipos em tipos não é uma opção.

Se você importar algo de um módulo, ainda obterá as tipificações TypeScript. A opção types é para tipos de importação automática para as declarações globais. Isso não é necessário com muita frequência, então não deve ser tão ruim adicionar manualmente esses módulos a types . É assim que eu entendo. Nossa base de código TS bastante grande com configurações de TS muito rígidas ainda funcionou após definir o array types como [] .

Veja por exemplo https://stackoverflow.com/a/59030291

a desvantagem é que, se você usar compilerOptions.types todas as suas digitações precisarão ser listadas aqui, pois qualquer coisa não incluída nesta lista será excluída. Então, para os pacotes instalados que fornecem tipificações, você precisará gerenciar esta configuração manualmente

Como disse @sbush , isso não é verdade. Essa opção é apenas para tipos globais, tipificações de import ed libs 'serão usadas sem problemas. A proposta de @Jessidhia é inofensiva.

Não acho que um único pacote deva forçar os consumidores a romper com a convenção que é deixar esse campo de lado. Como tudo o mais, isso não é uma solução, mas uma solução alternativa.

Não tenho certeza se alguém já respondeu ao caso quando você tem um repo mono Lerna + yarn workspaces (muitas respostas). Para este caso, você pode usar a propriedade no-hoist para obter mais informações no site yarn

nas práticas em seu arquivo package.json :

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

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

A solução proposta por @nahumzs funciona se você estiver usando monorepos de fio. Nesse caso, evitamos que o react-native polua a pasta global node_packages, evitando duplicatas que, por sua vez, geram erros.

Em que ponto acabamos de dizer que há mais usuários do React Web do que usuários do React Native, e retiramos o suporte do React Native?

Houve algum progresso nesta questão? No momento, estamos na versão 4.1.8 de @ types / styled-components porque não podemos atualizar sem uma resolução ou utilizando uma solução alternativa, como excluir node_modules / @ types / react-native em um comando npm pós-instalação.

Oh f ** k, este problema realmente me causa muita dor.

Agora estou incorrendo no problema descrito aqui . Portanto, se eu atualizar para o Typescript mais recente, não posso nem usar @types/[email protected] . 😡😡😡 WTH.

De qualquer forma, esta parece ser uma duplicata de https://github.com/DefinitelyTyped/DefinitelyTyped/issues/33015.

No Appsome Solutions , tivemos o mesmo problema e o resolvemos com a regra "skipLibCheck": true, em um arquivo tsconfig.json.

No caso de alguém sentir o mesmo: Eu não queria habilitar skipLibCheck apenas para contornar esse problema. Mas mudei de ideia agora que uma mudança recente habilitou skipLibCheck para novos projetos TypeScript - aparentemente por motivos de desempenho, mas posso imaginar também por causa de problemas como o que estamos vendo aqui.

talvez alguém ok com um hack muito sujo, você pode simplesmente adicionar à sua seção de package.json script:

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

Não é uma ótima solução, mas deve funcionar.

OMG, este problema ainda é real, mesmo para 5.1.1

1- Adicione um .yarnclean na raiz do projeto.
2- Insira o seguinte conteúdo: @types/react-native .

Isso resolvido aqui pelo menos enquanto espero por uma solução oficial.

Isso já vem acontecendo há mais de 1,5 anos. De qualquer forma, acho que meu problema está relacionado e estou recebendo muitos mais erros de "Identificadores duplicados". 36 no 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 da compilação com tsc :

Total: 38 erros. Apenas 2 deles são da minha fonte real de projeto src/**.* files. Os outros 36 erros são de .d.ts conflitos causados ​​por @types/styled-components .

Observação: se eu adicionar a sinalização "skipLibCheck": true , os erros desaparecem. Além disso, se eu remover @types/styled-components , os erros também desaparecerão.

Não vou postar o log completo aqui, mas aqui estão alguns exemplos.

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

A solução que estou adotando neste momento é remover @types/styled-components e prosseguir com meu projeto (que é um aplicativo da web React).