Typescript: Erro "Não é possível gravar o arquivo ... porque sobrescreveria o arquivo de entrada."

Eu também tenho o mesmo problema.

está --allowjs definido? você pode compartilhar o projeto?

Não posso compartilhar o projeto e não, esse sinalizador não está definido. Meu tsconfig.json está acima, e nós apenas usamos isso com a atualização 3 do VS2015, que apenas dispara a compilação com o MSBuild normalmente.

Tenho colegas de equipe reclamando sobre o mesmo problema acontecendo com eles nos mesmos projetos. Eu também trabalho em um projeto em casa em um computador diferente que tem exatamente o mesmo problema e a mesma configuração (TS 2.2.1, VS2015 U3, etc.)

você vê o mesmo comportamento se criar um projeto básico com as mesmas configurações?

Temos o mesmo problema https://github.com/wc-catalogue/blaze-elements/issues/299 embora com acesso de gravação de definições de tipo

@Hotell você vê isso sem "awesome-typescript-loader"? você pode compartilhar as etapas de reprodução comigo?

sim, como você pode ver no problema, a saída é da execução bruta tsc segunda vez.

basta clonar o repo https://github.com/wc-catalogue/blaze-elements

• acertar yarn da raiz
• hit yarn tsc -> compilação da primeira vez (está tudo bem) => primeira vez definitions/ pasta gerada
• acertar yarn tsc novamente -> erros

Estamos tendo um problema semelhante - mesma versão do typescript (2.2.1) e Visual Studio 2015 (atualização 3); na primeira vez que o build é executado, não há erros, mas depois disso obtemos centenas desses erros.

Parece que todos os erros (para nós) estão na pasta "node_modules", que definimos para excluir em nosso arquivo tsconfig.json. - Olhando para bugs semelhantes, parece que as exclusões não são tratadas da mesma forma nesta versão do texto datilografado?

Nosso arquivo tsconfig.json:

{
  "compilerOptions": {
    "noImplicitAny": false,
    "noEmitOnError": true,
    "removeComments": false,
    "sourceMap": true,
    "target": "es5",
    "module": "commonjs",
    "moduleResolution": "node",
    "emitDecoratorMetadata": true,
    "experimentalDecorators": true
  },
  "exclude": [
    "node_modules",
    "wwwroot",
    "aot",
    "AngularApp/main-aot.ts"

  ],
  "compileOnSave": true
}

Alguns dos erros que recebemos (são todos iguais, mas arquivos diferentes):

Severity    Code    Description Project File    Line    Suppression State
Error   TS5055  Cannot write file 'C:/XYZ/Project.AppWeb/node_modules/zone.js/dist/zone.js' because it would overwrite input file.  TypeScript Virtual Projects     1   Active
Error   TS5055  Cannot write file 'C:/XYZ/Project.AppWeb/node_modules/events/events.js' because it would overwrite input file.  TypeScript Virtual Projects     1   Active
Error   TS5055  Cannot write file 'C:/XYZ/Project.AppWeb/node_modules/core-js/modules/_wks.js' because it would overwrite input file.   TypeScript Virtual Projects     1   Active
Error   TS5055  Cannot write file 'C:/XYZ/Project.AppWeb/node_modules/core-js/modules/_uid.js' because it would overwrite input file.   TypeScript Virtual Projects     1   Active
Error   TS5055  Cannot write file 'C:/XYZ/Project.AppWeb/node_modules/core-js/modules/_to-primitive.js' because it would overwrite input file.  TypeScript Virtual Projects     1   Active

Novamente, se excluirmos a pasta "node_modules", a construção funcionará uma vez, mas depois de recriada, falhará na próxima reconstrução.

@Hotell não estou vendo isso localmente, o que estou perdendo?

c:\test\14538\blaze-elements>yarn tsc
yarn tsc v0.18.1
$ "c:\test\14538\blaze-elements\node_modules\.bin\tsc"
Done in 5.46s.

c:\test\14538\blaze-elements>yarn tsc
yarn tsc v0.18.1
$ "c:\test\14538\blaze-elements\node_modules\.bin\tsc"
Done in 5.87s.

c:\test\14538\blaze-elements>dir /B definitions
packages
polyfills.d.ts
styles.d.ts
test-helpers.d.ts
vendors.d.ts

c:\test\14538\blaze-elements>yarn tsc
yarn tsc v0.18.1
$ "c:\test\14538\blaze-elements\node_modules\.bin\tsc"
Done in 4.48s.

@ BrainSlugs83 se você tiver um projeto de reprodução, eu adoraria dar uma olhada.

Também estou enfrentando o mesmo problema, estes são os erros:

E este é meu tsconfig.json:

Como não estou usando nenhum tipo de texto, acabei de criar tsconfig para pular a compilação, também tive que escolher target = ES6, caso contrário, estava tendo outros erros.

o tsconfig.json faz parte do seu projeto? e você pode confirmar se o tipo de conteúdo é "Conteúdo"? se sim, você pode compartilhar seu projeto?

@mhegazy Olá, sim, posso confirmar que tsconfig.json está incluído no projeto:

Mas lamento não saber a que "tipo de conteúdo" se refere, pode esclarecer?

Não posso compartilhar o projeto.

No meu projeto, também posso confirmar se o arquivo tsconfig está incluído no arquivo do projeto e está listado como conteúdo.

@ max-favilli Acho que @mhegazy significa "Ação de construção" quando se fala em "tipo de conteúdo".

Selecione tsconfig.json no explorador de soluções. Abra a janela Propriedades (tecla F4 por padrão). Haverá uma propriedade Build Action.

Obrigado @kevindqc , @mhegazy yes "Build Action" está definido como "content"

Você pode compartilhar sua estrutura de projeto virtual comigo, para que você:

• vá para Tools > Options > Text Editor > TypeScript > Project e verifique Display Virtual Projects when no Solution is loaded ;
• reinicie o VS e abra um arquivo em seu projeto
• agora você deve ver um novo nó em seu Gerenciador de Soluções com o nome de TypeScript Virtual Project

@mhegazy assim?

Obrigado por ajudar.

Eu tenho o mesmo problema. Também não posso compartilhar o projeto, mas tentarei fornecer o máximo de informações possível.

Eu tenho a compilação de typescript desativada no .csproj ( <TypeScriptCompileBlocked>true</TypeScriptCompileBlocked> )
Em vez disso, é compilado por npm run build:prod , que está em um evento de construção.

Os erros nem sempre estão lá. Tenho tentado fazê-los aparecer (eram mostrados no VS, então reiniciei o VS). Eu tentei construir o projeto de texto digitado, construir a solução, executar testes, executar análise de código, executar cobertura de código, etc. Nada o aciona. Então, quando eu estava escrevendo a última frase, os erros apareceram. Então, parece que algumas tarefas em segundo plano fazem isso? Parece acontecer cerca de 2 minutos depois de iniciar uma compilação (pelo menos 2 ou 3 vezes que experimentei)

Linha do tempo:
1:37:20 - Visual Studio aberto
1:37:30 - Criação da solução iniciada
1:38:20 - Construção concluída
1:39:39 - Apareceram erros

Percebi que meu projeto ainda estava usando os pacotes v2.0.3 Microsoft.TypeScript.Compiler e Microsoft.TypeScript.MSBuild nuget. Eu os atualizei para v2.2.1. Até agora, nenhum erro. Será atualizado se eu ver os erros novamente. (Editar: vejo os erros novamente, embora tenha demorado um pouco mais, ~ 5 minutos, sem que eu fizesse nada além de compilar quando abri o VS. Na verdade, eu nem preciso construir nada para obter o erro - apenas abrindo o projeto e esperar alguns minutos mostra os erros)

Sobre esses pacotes nuget desatualizados, isso é normal? Acho que recebi um pop-up para atualizar minhas ferramentas de datilografia do projeto quando instalei a nova versão do typescript, mas parece que só atualizou <TypeScriptToolsVersion>2.2</TypeScriptToolsVersion> . Ele também não deveria atualizar os pacotes nuget?

Acabei de atualizar para o Typescript 2.2.1 e estou tendo o mesmo problema. É sinalizado todos os node_modules, mas o compilador tsc é concluído sem problemas.

@mhegazy

@Hotell não estou vendo isso localmente, o que estou perdendo?

certo, foi corrigido por https://github.com/wc-catalogue/blaze-elements/commit/cdb94bf8feb3a1ad7e21e6fce243e3322c1334cc

sry para resposta atrasada e thx 4 help!

@Hotell @mhegazy Não parece funcionar para mim.
Talvez funcione se você tiver arquivos d.ts em uma pasta de "definições"?
Mas eu não tenho isso. Eu tenho @types em "node_modules" que devem ser excluídos por herança?

@chrismbarr Posso perguntar se você já resolveu isso? Tenho seguido o tópico e até fiz a correção sugerida por alguns posts do @Hotell, mas ainda estou recebendo esses erros no Visual Studios. Todos eles parecem vir da pasta node_modules.

Você poderia habilitar o registro detalhado e nos enviar os resultados? Defina a variável de ambiente do sistema TSS_LOG para um valor como -file C:/temp/logs/tsserver.log -level verbose (certifique-se de que a pasta de logs existe). Depois de reproduzir o problema, envie / anexe o log para análise. (Observação: pode conter dados como caminhos de arquivo e listas de conclusão, portanto, certifique-se de que não haja dados que você não queira compartilhar).

Em meus testes, ocasionalmente vi o sistema de projeto construir uma visão do projeto que contém os arquivos errados, causando erros intermitentes em momentos imprevisíveis. Eu gostaria de ver se essa pode ser a causa aqui.

Posso fornecer meu endereço de e-mail se você preferir enviar os arquivos diretamente em vez de carregá-los (billti at microsoft dot com). Obrigado.

@johnlee não, ainda o mesmo no VS2015. No entanto, comecei a usar o Visual Studio 2017 e não tenho erros!

@billti Variável adicionada, visual studio (2017) reiniciado, solução reconstruída, mas o arquivo de log não está sendo criado. O que devo verificar?

É definitivamente uma variável de ambiente do sistema (ou seja, se você abrir um novo prompt de comando e executar SET TSS a configuração está listada)? Caso contrário, é a pasta na qual o log deve ser gravado já está presente (o logger não criará diretórios que não existam). Fora isso, também é mais seguro usar barras normais em vez de barras invertidas no caminho.

:(

@billti Ok, acabei de verificar e os arquivos de log estão lá agora. Encontre-os aqui em anexo
tss-log.zip

Obrigado. Dei uma olhada nesse log e não vejo esse erro sendo relatado por nenhuma chamada nele. O erro definitivamente ocorreu no intervalo de tempo que este registro cobre?

@billti Sim, os erros estão ocorrendo o tempo todo:

Eles estão lá permanentemente. E atualizado a cada construção.

Todos esses erros relacionados a declarações de variáveis ​​incorretas (um problema separado que já corrigimos para uma versão futura). Este problema é cerca de Cannot write file... acordo com o título e as capturas de tela acima. Você não tem o problema de Cannot write file... ?

@billti depois de postar minha mensagem anterior (que deixei lá como uma demonstração de minha estupidez), percebi que os erros são de um tipo diferente. Só posso supor que a atualização do Visual Studio que instalei há alguns dias resolveu o problema original. Mas eu não tenho certeza.
Eu me livrei desses erros da mensagem anterior apenas removendo os tipos de @types.
Muito obrigado.

@billti Estou tentando enviar alguns logs para você, mas nenhum foi criado. Eu defini TSS_LOG para -file C:/temp/logs/tsserver.log -level verbose em minhas variáveis ​​de sistema (não de usuário).

C:\temp\logs existe e dei controle total a Everyone .

Se eu reiniciar meu VS2015, nada será criado dentro de C:\temp\logs mesmo depois de eu receber todos os meus Cannot write file... erros. Se eu tentar digitar node node_modules\typescript\lib\tsserver.js (e CTRL + C imediatamente) em um novo prompt de comando, obtenho dois arquivos de log.

Desculpe @kevindqc , não sabia que você estava no VS 2015. Esse registro se aplica apenas ao VS 2017 (que agora usa tsserver.js fora do processo para o serviço de linguagem).

Voltando atrás e olhando para o seu problema - se você está vendo a lista de erros mudar aleatoriamente, acredito que seja o mesmo problema que @zhengbli acabou de corrigir em https://github.com/Microsoft/TypeScript/pull/15080 .

@billti np. Acho que esse problema só está acontecendo no VS2015, não? O único usuário com problema que estava usando o VS2017 estava tendo diferentes erros relacionados à digitação. Alguém que mudou do VS2015 para o VS2017 disse que o problema foi embora.

Além disso, a lista de erros não muda aleatoriamente - ela é preenchida em um momento aleatório, uma vez, com todos os erros "Não é possível escrever .." relacionados a esse problema. Tem certeza de que # 15080 corrige isso? Não vejo nada sobre esse problema, exceto a referência que você fez a ele ontem. Como posso testar? Vejo que há um 2.3 RC, mas foi lançado 9 dias atrás, enquanto a correção foi mesclada 2 dias atrás :(

Também notei que os erros permanecem na minha lista de erros mesmo depois de fechar a solução.

Além disso, a pessoa que postou seu projeto virtual datilografado foi aquela com os diferentes erros, então imagino que não tenha sido útil. Aqui é minha:

node_modules deveria estar lá? Está no meu tsconfig exclui. No entanto, ele não contém tudo o que minha pasta física node_modules tem (14 subpastas vs 854 subpastas em minha pasta node_modules)

{
  "compilerOptions": {
    "emitDecoratorMetadata": true,
    "experimentalDecorators": true,
    "module": "commonjs",
    "moduleResolution": "node",
    "noImplicitAny": true,
    "removeComments": false,
    "sourceMap": true,
    "suppressImplicitAnyIndexErrors": true,
    "target": "es5",
    "baseUrl": "./src",
    "skipLibCheck": true,
    "paths": {
    },
    "typeRoots": [
      "node_modules/@types"
    ]
  },
  "exclude": [
    "node_modules",
    "dist",
    "typings"
  ],
  "types": [
    "core-js",
    "jasmine",
    "lodash",
    "node",
    "webpack"
  ],
  "awesomeTypescriptLoaderOptions": {
    "forkChecker": true,
    "useWebpackText": true
  }
}

Não tive os erros até agora após a atualização para as ferramentas TS2.3. Obrigado!
Editar: Nop. Afinal, os erros ainda estão lá, só demoraram mais para aparecer.

Parece que este problema está relacionado com este problema . Solução de amostra para reproduzir - carregado.

Eu encontrei uma solução para mim. No meu caso, usei outDir e rootDir sem especificar o array files . Ao adicionar o caminho de outDir ao array exclude tudo parece estar funcionando normalmente.

{
    "compilerOptions": {
        ...,
        "outDir": "./dist",
        "rootDir": "./src",
    },
    "exclude": [
        "node_modules",
        "dist" <-- I had to add this to fix the errors
    ]
}

Talvez o TypeScript também esteja monitorando o conteúdo da pasta dist , embora esteja definida como outDir .

Se você tem outDir na raiz do projeto e está apenas incluindo tudo na raiz, isso seria o esperado. Geralmente, você deseja que a saída da construção em algum lugar diferente da pasta de origem do projeto.

Parece que todos os problemas acima são abordados neste tópico ou problemas vinculados. Avise-me se não for o caso e reabrirei. Obrigado!

@billti Presumo que seu comentário seja uma resposta ao meu comentário anterior. Em caso afirmativo, obrigado por esclarecer. Isso torna a questão mais óbvia para mim agora, pois presumi que ao especificar rootDir o compilador apenas observará aquela pasta em particular e excluirá todo o resto. Mas o comportamento atual faz sentido.

a melhor solução é de borislemke .
{ "compilerOptions": { ..., "outDir": "./dist", "rootDir": "./src", }, "exclude": [ "node_modules", "dist" <-- I had to add this to fix the errors ] }

Eu tive o mesmo problema e descobri que uma das minhas importações estava referenciando incorretamente a classe na minha pasta dist EG
importar {ClassName} de "../../dist/ClassName";

Como a classe de importação estava na mesma pasta, mudei para:
importar {ClassName} de "./ClassName";

e tudo está compilando novamente :)

Tínhamos uma pasta 'dist' predefinida em nosso aplicativo. Excluir isso consertou para mim.

Acho que esse é o problema subjacente (a última atualização do Windows Creators):
visual-studio-2015-deletes-file-on-save-cordova-solution

Basta adicionar sua pasta "dist" à lista de exclusões em tsconfig.json
ex:
"exclude": ["node_modules", "dist"]

Corrigi isso adicionando uma seção Incluir:

"include": [ "*.ts", ], "exclude": [ "node_modules" ]

Também encontrei isso ao usar um outDir que estava sob meu diretório de fontes.

Como é que o compilador de texto digitado não sabe por padrão que não deve tentar compilar coisas no outDir ? Isso parece estranho. No entanto, adicionar o outdir à lista de exclusão corrigiu o problema.

eu tenho esse problema com netbeans lol 👎

Também recebi este erro quando tinha dois arquivos foo.ts e foo.tsx , ambos compilando para foo.js , obviamente.

  "compilerOptions": {
    "noEmit": true 
  }

Consertou para mim.

noEmit é uma solução melhor se você quiser ter gerado *.js arquivos a serem analisados. Afinal, eles não são necessariamente gerados com tsc .

No meu caso, Ream.js gera .ream/**.js que eu importo com import XXX from '#out/yyy' no meu código (que funciona, mas gera o aviso "Não é possível gravar o arquivo ..." no código do VS).

Basicamente, a única razão para ter "noEmit": false é quando você usa tsc bruto. Para todos os outros ambientes ( ts-node / ts-node-dev , webpack, rollup) é mais seguro habilitá-lo.

Como @uglycoyote, o que funcionou para mim foi adicionar outdir ao array excludes. Nenhuma das outras sugestões funcionou.

Acho que esse problema está relacionado a:

• https://github.com/TypeStrong/ts-node/issues/270
• https://github.com/Microsoft/TypeScript/issues/9858
• https://github.com/Microsoft/TypeScript/issues/11299

O problema está acontecendo comigo porque eu configurei "declaration": true no tsconfig.json , então ele fica irritado com os d.ts arquivos na pasta de compilação, mesmo que o diretório esteja fora do raiz. Posso fazer uma nova compilação sem problemas, mas qualquer compilação depois disso gerará: Cannot write file ... because it would overwrite input file. . Pelo que pude ver nas outras histórias, isso funcionava em outra versão, então algo deve ter mudado.

Assim como eu corrigi os problemas sobre meus test.ts arquivos estarem fora de rootDir eu tive que adicionar o seguinte a tsconfig.json .

"exclude:" [ "./build" ]

Isso também pode acontecer com herança de configuração. Cada configuração precisará especificar outDir separadamente. Parece que o caminho em outDir é resolvido em termos absolutos. Pode até ser um bug do ponto de vista do usuário.

{
  "extends": "../../base/tsconfig.json",
  "compilerOptions": {
    "outDir": "myOutDir"  // <--- Don't forget this
  }
}

Vale a pena verificar também se você tem uma referência errônea dentro de package.json para "outDir"

"main": "lib/index.js",
  "typings": "lib/__types__",      <-------
  "devDependencies": {
    "@types/lodash.mapvalues": "^4.6.4",
    "@types/node": "^10.12.18",
    "@types/winston": "^2.4.4"
  }

Eu experimentei isso em um projeto com referências de projeto. Nenhuma das exclusões importou, o que fez foi a entrada typings sugerida por @elmpp.

Portanto, isso produzirá TS5055: Cannot write file because it would overwrite input file em um projeto de referência monorepo:

  "main": "lib/cjs/index.js",
  "module": "lib/esm/index.js",
  "typings": "lib/cjs/index.ts",

mas isso não relatará erros:

  "main": "lib/cjs/index.js",
  "module": "lib/esm/index.js",
  "typings": "src/index.ts",

Então, evidentemente, precisarei manipular essa pré-publicação ou publicar o src no pacote.

Configuração:

"exclude": [
    "node_modules",
    "dist"
  ]

consertou para mim (meu outputDir era dist ).

Pode ser incrível se o diretório de saída for excluído por padrão para tsc --watch .

Para referência futura, isso acontece se você importar um módulo de dentro dele.

Então, fazer import x from 'mymodule dentro de mymodule irá acionar isso. É muito enigmático e provavelmente deve ser consertado!

Da mesma forma, encontrei o problema se você tiver um index.ts com um monte de linhas como export * from './foo' , e em um desses arquivos, eu estava importando com import foo from '.' vez de import foo from './foo' em um dos arquivos exportados.

Bati minha cabeça nisso nos últimos dois dias até que excluí index.ts e tive um erro de importação. Não era nada óbvio.

Então eu acho que o problema era porque eu tenho 2 projetos ts no mesmo repo. (Angular & Nestjs), o tsconfig.json da pasta de nível 1 está gerando este erro. Consertei colocando exclude "public", que em public é meu código Angular com seu próprio tsconfig.json.

Eu estava tendo esse problema porque não tinha certeza de por que ts-node não estava funcionando, então tsc para verificar se o problema era TypeScript. Como resultado de tsc , eu agora tinha dezenas de .js arquivos lado a lado com ts que eu poderia confirmar executando git status

A solução foi git clean -f .

No meu caso, parece que o VS Code importou automaticamente um arquivo da pasta dist vez da pasta src . Consertar isso resolveu o problema.

Isso realmente não deve ser fechado, o texto digitado deve imprimir um erro informando o que está acontecendo. É quase impossível descobrir atualmente. Não tenho certeza do que causa isso de vez em quando, VSCode talvez atualizando referências tsconfig.json acidentalmente, mas torna tudo mais lento e cada vez não tem sido trivial para depurar.

no projeto Vue, na raiz, funcionou para mim:

// tsconfig.json
{
    "include": ["./src/**/*"],
    "exclude": ["node_modules", "dist", "public"],
    "compilerOptions": {
      "module": "es2015",
      "outDir": "",
      "moduleResolution": "node",
      "target": "es5",
      "allowJs": true,
      "checkJs": true, // Type checking
    }
}

Depois de adicionar o
"outDir": "",
problema foi embora.

Meu objetivo aqui é apenas fazer sua inteligência funcionar em arquivos .js / vue.

Teve a mesma mensagem de erro. O problema era que eu tinha dois arquivos com o mesmo nome, mas com extensão diferente na mesma pasta, portanto, remover aquele com .js extensão corrigiu isso.

Teve a mesma mensagem de erro. O problema era que eu tinha dois arquivos com o mesmo nome, mas com extensão diferente na mesma pasta, portanto, remover aquele com .js extensão corrigiu isso.

Sim, eu tive o mesmo problema. Eu renomeei um .tsx arquivo .ts que o VS-Code recriou de forma útil, causando o problema.

Não tenho certeza de como resolver isso corretamente, mas no meu caso, acabei de remover "declaration": true de tsconfig.json. Os arquivos D.ts não são produzidos, mas eu não preciso deles de qualquer maneira.

Para qualquer pessoa que veio aqui pesquisando uma mensagem de erro semelhante, deixe-me compartilhar minhas descobertas:

1. Como você pode ler, esse erro foi causado porque o compilador TypeScript estava tentando compilar um arquivo .js no mesmo caminho.
2. Provavelmente você não deseja compilar arquivos .js. Se possível, remova allowJs: true de seu tsconfig.json ou --allow-js de suas opções de CLI.
3. No caso de você definitivamente precisar deles, então você pode querer excluir os arquivos que foram mencionados na mensagem de erro da compilação. Algumas pessoas neste tópico fizeram isso (talvez sem perceber) adicionando exclude: ... .
   
   
   
   • Tenha cuidado para não adicionar 'excluir' em compilerOptions .
   
   

Espero que ajude 🙏

Eu precisava excluir manualmente meu diretório lib/ compilação

Parece haver um bug em algum lugar que torna algumas opções incompatíveis. Eu descobri isso usando
allowJS true +
rootDir + outDir : OK
rootDir + outFile : NOK: rootDir não levado em consideração: todos os arquivos em dir e subdiretório são configurados para serem compilados e potencialmente sobrescritos.
algumas outras combinações de opções são proibidas.

"allowJs": true
"noEmit": true
trabalhe para mim.

no projeto Vue, na raiz, funcionou para mim:

// tsconfig.json
{
    "include": ["./src/**/*"],
    "exclude": ["node_modules", "dist", "public"],
    "compilerOptions": {
      "module": "es2015",
      "outDir": "",
      "moduleResolution": "node",
      "target": "es5",
      "allowJs": true,
      "checkJs": true, // Type checking
    }
}

Depois de adicionar o
"outDir": "",
problema foi embora.

Meu objetivo aqui é apenas fazer sua inteligência funcionar em arquivos .js / vue.

obrigado, funciona para mim.

Se você estiver usando o TS APENAS para .js , use a solução @ guaizi149 :

"compilerOptions": {
  "allowJS": true,
  "noEmit": true
}

Isso dirá ao TS que ele não deve se preocupar com a compilação, portanto, nenhum arquivo será sobrescrito e nenhum aviso será acionado. Esta é a melhor solução para usar outDir: "" .

Isso também pode acontecer com herança de configuração. Cada configuração precisará especificar outDir separadamente. Parece que o caminho em outDir é resolvido em termos absolutos. Pode até ser um bug do ponto de vista do usuário.

{
  "extends": "../../base/tsconfig.json",
  "compilerOptions": {
    "outDir": "myOutDir"  // <--- Don't forget this
  }
}

Esta solução funcionou como um encanto para mim! Meu tsconfig.json tem esta aparência agora:

{
  "compilerOptions": {
    "allowJs": true,
    "baseUrl": "../node_modules",
    "types": ["cypress"],
    "outDir": "myOutDir"
  },
  "include": ["**/*.*"]
}

"allowJs": true
"noEmit": true
trabalhe para mim.

Obrigado @ guaizi149 , sua solução funciona para mim 👍

Resolvido - incluí o diretório dist na minha compilação tsc:

"exclude": [
    "node_modules"
  ]

--- vai para

"exclude": [
    "node_modules",
    "dist"
  ]

dist sua pasta de compilação?

Se excluir outDir não funcionou para você, tente verificar se você tem arquivos duplicados com o mesmo caminho e nome de arquivo, mas com extensões diferentes.

Isso acontece quando os arquivos de declaração não são excluídos da construção. Sempre que isso ocorre, o construtor tenta construir os arquivos ".d.ts" existentes e substituí-los pelo mesmo nome de arquivo. É por isso que você obterá o erro: Cannot write file ... because it would overwrite input file.

Para evitar isso, você pode excluir seu "outDir":"build" no arquivo jour tsconfig.json:

"exclude": [
    "build",
    ....
]

ou se você não tiver outDir definido, exclua todos os d.ts . arquivos de extensão:

"exclude": [
    "**/*.d.ts"
    .....
]

Espero que isto ajude

@Abadii : talvez seja porque estou usando a opção -b durante a compilação, mas nenhuma dessas abordagens funcionou.

@Abadii : talvez seja porque estou usando a opção -b durante a compilação, mas nenhuma dessas abordagens funcionou.

Você pode compartilhar seu arquivo tsconfig.json e qual versão é seu tsc ?

@Abadii : Aqui está (sem a exclusão atualizada, obviamente). A versão de tsc é 3.8.3:

{
    "compilerOptions": {
        "importHelpers": true,
        "target": "es6",
        "module": "CommonJS",
        "lib": ["es2018"],
        "downlevelIteration": true,
        "skipLibCheck": true,
        "strict": true,
        "moduleResolution": "node",
        "esModuleInterop": true,
        "experimentalDecorators": true,
        "outDir": "../lib",
        "sourceMap": true,
        "declaration": true
    },
    "exclude": ["node_modules"]
}

@Abadii : Aqui está (sem a exclusão atualizada, obviamente). A versão de tsc é 3.8.3:

{
    "compilerOptions": {
        "importHelpers": true,
        "target": "es6",
        "module": "CommonJS",
        "lib": ["es2018"],
        "downlevelIteration": true,
        "skipLibCheck": true,
        "strict": true,
        "moduleResolution": "node",
        "esModuleInterop": true,
        "experimentalDecorators": true,
        "outDir": "../lib",
        "sourceMap": true,
        "declaration": true
    },
    "exclude": ["node_modules"]
}

Por favor, dê uma olhada no seguinte repo. Usei seu tsconfig.json para gerar o erro novamente:

https://github.com/Abadii/tsconfig

PS E o que acontecerá quando você excluir sua pasta ../lib? Será que vai construir?

@Abadii : Ele será compilado se eu remover a pasta de compilação (na verdade, só será compilado se eu remover / esvaziar a pasta de compilação). Isso é verdade mesmo se eu exclude arquivos de declaração e a pasta de construção.
Para sua informação, a estrutura do projeto é assim:

project\
  lib\
    session.d.ts
    session.js
  src\
    session.ts
    tsconfig.json
  package.json 

e eu construo com: tsc -p ./src/tsconfig.json
(na verdade, geralmente eu construo com rm -rf ./lib && tsc -p src/tsconfig.json mas é isso que estou aqui para consertar;))

@Abadii : Ele será compilado se eu remover a pasta de compilação (na verdade, só será compilado se eu remover / esvaziar a pasta de compilação). Isso é verdade mesmo se eu exclude arquivos de declaração e a pasta de construção.

Agora você sabe que a pasta de construção está causando o problema. De alguma forma, sua construção tsc não exclui sua pasta de construção. Você pode tentar usar o caminho absoluto na exclusão.
Também observei que sua pasta de construção está fora do seu escopo ../lib . Talvez seja essa também a razão pela qual não exclui. Tente ./lib as outDir para verificar se isso muda o comportamento
Se você for um usuário do Windows, verifique se o caminho absoluto definido está correto.

@Abadii : Obrigado, mas não posso usar caminhos absolutos, pois trabalho no projeto em várias máquinas e não posso garantir uma estrutura de pasta idêntica em todas elas. Para mim, isso parece um bug - digo ao tsconfig para excluir os arquivos de pasta e declaração, mas não o faz. Isso deve ser reaberto?

@Abadii : Obrigado, mas não posso usar caminhos absolutos, pois trabalho no projeto em várias máquinas e não posso garantir uma estrutura de pasta idêntica em todas elas. Para mim, isso parece um bug - digo ao tsconfig para excluir os arquivos de pasta e declaração, mas não o faz. Isso deve ser reaberto?

Entendo, talvez a última coisa que você possa tentar é colocar seu arquivo tsconfig em project/tsconfig.json e alterar os caminhos. Eu também estou sem opções se isso não funcionar, eu acho.

Tentou:

1. Configurando outDir -> não.
2. Configurando allowJs: false -> não.
3. Excluindo .d.ts -> não.
4. noEmit: true -> não.

Eu tentei todas as sugestões neste tópico. Não apenas o erro VSCode persiste, mas também se refere a um arquivo que não existe mais. 🤷‍♂️

Tentou:

1. Configurando outDir -> não.
2. Configurando allowJs: false -> não.
3. Excluindo .d.ts -> não.
4. noEmit: true -> não.

Eu tentei todas as sugestões neste tópico. Não apenas o erro VSCode persiste, mas também se refere a um arquivo que não existe mais.

O que acontece quando você tenta construir diretamente através do terminal?

Defina um outDir e certifique-se de deixá-lo vazio antes de construir

@Abadii Então .... parece que isso estava acontecendo porque, embora os arquivos JS não estivessem incluídos, eles estavam falhando porque eram módulos CommonJS .... 🤔 ....

Em outras palavras, uma vez que tudo teve importação / exportação adequada, parei de ter esse problema. Portanto, com base nos comentários deste tópico e no grande número de correções, acho que esse é um daqueles erros de arenque vermelho. Como em, quando há o tipo X de JS / Intellisense / problema de compilação, o VSCode gera este erro Cannot write file . Mas, no meu caso, isso foi resolvido com uma solução OUTRA do que qualquer outra das inúmeras soluções oferecidas neste segmento. 🤷‍♂️ E novamente, ele gerou esse erro em um arquivo que _não existia_ e _não seria substituído_. Então, talvez os erros estejam em cache e um erro desconhecido gere um erro em cache? Algo parecido? Acho que alguém precisa inspecionar o código em torno desse erro específico.

Comentando aqui porque é a primeira coisa que surgiu na minha busca no google.

Eu também encontrei esse problema. Parece que alguma parte do processo de compilação não está reconhecendo que está dentro de um diretório excluído.

Não vejo problema se eu fizer isso:

  "exclude": ["**/*.d.ts", "dist", "node_modules"]

Eu vejo o problema se eu fizer isso:

  "exclude": ["dist/**/*.d.ts", "dist", "node_modules"]

ou isto:

  "exclude": ["**/dist/**/*.d.ts", "dist", "node_modules"]

O erro ocorre apesar do fato de que os arquivos sobre os quais ele está reclamando estão claramente dentro de dist :

error TS5055: Cannot write file '/Users/leila/dev/wip/jest-fp-ts/dist/index.d.ts' because it would overwrite input file.
error TS5055: Cannot write file '/Users/leila/dev/wip/jest-fp-ts/dist/matchers/index.d.ts' because it would overwrite input file.

No meu caso, tenho importações configuradas onde src/index.ts importa e reexporta de src/matchers/index.ts que, por sua vez, importa e reexporta de src/matchers/eitherMatchers/index.ts .

Os primeiros dois arquivos são os que causam os erros de compilação. O terceiro arquivo está bem. Portanto, parece que pode estar relacionado a como a árvore de importação / exportação está afetando a compilação.

Eu simplesmente me deparei com esse problema enquanto tinha o mesmo problema, e pensei em acrescentar o que o meu acabou sendo no caso de outras pessoas tropeçarem nele da mesma maneira.

No meu caso, tenho um monorepo com um arquivo tsconfig separado para cada pacote, que se estende a partir de um tsconfig base. Cada configuração de pacote tem references entradas que apontam para o caminho dos pacotes dos quais depende. Também tenho um tsconfig.json na raiz do repo que inclui files: [] e tem referências a todos os diretórios de pacotes. Desta forma, posso executar tsc -b --watch partir da raiz e fazer com que seja reconstruído nas alterações em todo o projeto.

Isso funcionou bem por um bom tempo, depois começou abruptamente a gerar esse erro, embora nenhuma das configurações tivesse sido alterada.

Finalmente rastreei tentando construir o único pacote que estava sendo relatado no erro sozinho, em vez de construir o projeto inteiro.

Acontece que o problema era que eu tentei importar o próprio projeto. O nome do pacote era @my-project/utils e funcionou bem até que movi algum código de outro pacote para um arquivo no pacote utils. Esse código incluía import stuff from '@my-project/utils'; e foi isso que causou o erro. Ao mudar para import stuff from '.'; o erro foi embora.

@jasonk Isso provavelmente está apenas revelando minha ignorância, mas isso só funcionaria se o seu monorepo estivesse sendo agrupado por algo que resolverá todas essas importações (por exemplo, webpack)? Se o seu monorepo for composto de módulos que podem ser publicados e usados ​​independentemente, mudar para importações relativas causaria erros, não?

@Ghirigoro Não, o problema não era que eu estava usando um caminho de pacote, mas sim um caminho de pacote para importar um pacote de dentro dele. Mesmo sem o Typescript, isso não funcionará.

Basicamente, o que eu fiz foi o equivalente a isto:

$ mkdir problem
$ cd problem
$ npm init -y
$ echo 'console.log( "WORKED!" );' > index.js
$ echo 'require( "problem" );' > test.js

Se você tentar executar isso com o nó:

$ node ./test.js
internal/modules/cjs/loader.js:985
  throw err;
  ^

Error: Cannot find module '/Users/jasonk/problem/test.js'
    at Function.Module._resolveFilename (internal/modules/cjs/loader.js:982:15)
    at Function.Module._load (internal/modules/cjs/loader.js:864:27)
    at Function.executeUserEntryPoint [as runMain] (internal/modules/run_main.js:74:12)
    at internal/main/run_main_module.js:18:47 {
  code: 'MODULE_NOT_FOUND',
  requireStack: []
}

Se você substituir o nome do pacote, ele funcionará corretamente:

$ echo 'require( "." );' > test.js
$ node ./test.js
WORKED!

Eu suspeito que o que aconteceu foi que quando a compilação foi executada, todos os outros pacotes que estavam importando de @my-project/utils tiveram aquela importação resolvida para packages/utils (porque eles tinham as entradas corretas no references array em tsconfig), então eles construíram normalmente. Mas como esse pacote não deveria estar se importando, a importação foi resolvida para node_modules/@my-project/utils , que era um link simbólico para packages/utils , mas o TypeScript não detectou que eles eram realmente o mesmo projeto, então ele tentou compilá-lo duas vezes, mas como ambas as compilações tinham o mesmo diretório de saída, obtive este erro.

Isso acontece quando os arquivos de declaração não são excluídos da construção. Sempre que isso ocorre, o construtor tenta construir os arquivos ".d.ts" existentes e substituí-los pelo mesmo nome de arquivo. É por isso que você obterá o erro: Cannot write file ... because it would overwrite input file.

Para evitar isso, você pode excluir seu "outDir":"build" no arquivo jour tsconfig.json:

"exclude": [
    "build",
    ....
]

ou se você não tiver outDir definido, exclua todos os d.ts . arquivos de extensão:

"exclude": [
    "**/*.d.ts"
    .....
]

Espero que isto ajude

Excluir meu diretório de construção resolveu o problema para mim

Provavelmente, isso acontece quando você tenta executar um projeto com dois nós.
Para esta hipótese, você pode testar a contagem de processos em seu computador com o nome "nó" após executar a compilação.
O que fiz para resolver o problema:
Passo 1.
Comparar
node -v
e
nvm -ls , a versão em uso.
No conjunto de terminais, versão do nó atual:
nvm use {neededVersion}
Em princípio, exclua versões desnecessárias do nó no nvm (isso ajudará seu IDE a determinar automaticamente a versão normal do nó).
Passo 2.
Determine o nó atual em seu IDE. ou seja, no WebStorm:
Preferências-> Idiomas e Frameworks -> Node.js e NPM: interpretador de Node - definir a versão necessária.
(Além disso, você pode verificar a versão do nó para cada item em todos os lugares (texto tipográfico))

Além disso, esse problema pode ocorrer se os pacotes npm ou submódulos git usaram seu próprio nó dentro

Eu estava enfrentando esse problema para o projeto Webdriver IO / WDIO. Foi resolvido quando removi "wdio.config.js" de "include" em tsconfig.json.