Typescript: Error "No se puede escribir el archivo ... porque sobrescribiría el archivo de entrada".

También tengo el mismo problema.

¿Está --allowjs establecido? ¿puedes compartir el proyecto?

Lo siento, no puedo compartir el proyecto y no, esa bandera no está configurada. Mi tsconfig.json está arriba, y solo lo usamos con VS2015 Update 3, que simplemente activa la compilación con MSBuild normalmente.

Tengo compañeros de equipo que se quejan del mismo problema que les ocurre en los mismos proyectos. También trabajo en un proyecto en casa en una computadora diferente que tiene exactamente el mismo problema y la misma configuración (TS 2.2.1, VS2015 U3, etc.)

¿Ves el mismo comportamiento si creas un proyecto básico con las mismas configuraciones?

Tenemos el mismo problema https://github.com/wc-catalogue/blaze-elements/issues/299 aunque con definiciones de tipo acceso de escritura

@Hotell , ¿ves esto sin "awesome-typescript-loader"? ¿Puedes compartir conmigo los pasos de reproducción?

sí, como puede ver en el problema, la salida proviene de ejecutar sin procesar tsc segunda vez.

simplemente clona el repositorio https://github.com/wc-catalogue/blaze-elements

• golpee yarn desde la raíz
• presione yarn tsc -> primera compilación (todo está bien) => primera vez definitions/ carpeta generada
• presione yarn tsc nuevo -> errores

Tenemos un problema similar: la misma versión de mecanografiado (2.2.1) y Visual Studio 2015 (Actualización 3); la primera vez que se ejecuta la compilación, no hay errores, pero después de eso, obtenemos cientos de estos errores.

Parece que todos los errores (para nosotros) están en la carpeta "node_modules", que hemos configurado para excluir en nuestro archivo tsconfig.json. - Al observar errores similares, ¿parece que las exclusiones no se tratan de la misma manera en esta versión de mecanografiado?

Nuestro archivo 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
}

Algunos de los errores que obtenemos (todos son iguales, pero archivos 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

Nuevamente, si eliminamos la carpeta "node_modules", la compilación funcionará una vez, pero una vez que se haya recreado, fallará en la siguiente reconstrucción.

@Hotell no veo esto localmente, ¿qué me estoy perdiendo?

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 si tienes un proyecto de reproducción, me encantaría echarle un vistazo.

También me enfrento al mismo problema, estos son los errores:

Y este es mi tsconfig.json:

Como no estoy usando mecanografiado en absoluto, acabo de crear tsconfig para omitir la compilación, también tuve que elegir target = ES6, de lo contrario, estaba teniendo otros errores.

¿Es tsconfig.json parte de su proyecto? y ¿puede confirmar que el tipo de contenido es "Contenido"? si es así, ¿puedes compartir tu proyecto?

@mhegazy Hola, sí, puedo confirmar que tsconfig.json está incluido en el proyecto:

Pero lo siento, no sé a qué "tipo de contenido" se refiere, ¿podría aclararlo?

No puedo compartir el proyecto.

En mi proyecto, también puedo confirmar que el archivo tsconfig está incluido en el archivo del proyecto y está listado como contenido.

@ max-favilli Creo que @mhegazy significa "Acción de compilación" cuando se habla de "tipo de contenido".

Seleccione tsconfig.json en el explorador de soluciones. Abra la ventana Propiedades (tecla F4 por defecto). Habrá una propiedad Build Action.

Gracias @kevindqc , @mhegazy sí "Acción de compilación" está configurada como "contenido"

¿Puedes compartir conmigo la estructura de tu proyecto virtual? Para conseguir lo que necesitas:

• vaya a Tools > Options > Text Editor > TypeScript > Project , y marque Display Virtual Projects when no Solution is loaded ;
• reinicie VS y abra un archivo en su proyecto
• ahora debería ver un nuevo nodo en su Explorador de soluciones con el nombre de TypeScript Virtual Project

¿A @mhegazy le gusta esto?

Gracias por ayudar.

Tengo el mismo problema. Tampoco puedo compartir el proyecto, pero intentaré brindar la mayor cantidad de información posible.

Tengo la compilación de mecanografiado deshabilitada en .csproj ( <TypeScriptCompileBlocked>true</TypeScriptCompileBlocked> )
En su lugar, está compilado por npm run build:prod , que está en un evento de compilación.

Los errores no siempre están ahí. He estado tratando de hacerlos aparecer (se mostraron en VS, así que reinicié VS). He intentado crear el proyecto de mecanografiado, crear la solución, ejecutar pruebas, ejecutar análisis de código, ejecutar cobertura de código, etc. Nada lo activa. Entonces, justo cuando estaba escribiendo la última frase, aparecieron los errores. Entonces, ¿parecen ser algunas tareas en segundo plano las que lo hacen? Parece suceder alrededor de 2 minutos después de que comencé una compilación (al menos las 2-3 veces que lo probé)

Línea de tiempo:
1:37:20 - Visual Studio abierto
1:37:30 - Se inició la compilación de la solución
1:38:20 - Construcción terminada
1:39:39 - Aparecieron errores

Noté que mi proyecto todavía estaba usando los paquetes v2.0.3 Microsoft.TypeScript.Compiler y Microsoft.TypeScript.MSBuild nuget. Los actualicé a v2.2.1. Hasta ahora, no hay error. Se actualizará si vuelvo a ver los errores. (Editar: veo los errores nuevamente, aunque tomó un poco más de tiempo, ~ 5 minutos, sin que yo hiciera nada más que construir cuando abrí VS. En realidad, ni siquiera necesito compilar nada para obtener el error, solo abriendo el proyecto y esperar unos minutos muestra los errores)

Acerca de esos paquetes nuget obsoletos, ¿es eso normal? Creo que aparece una ventana emergente para actualizar las herramientas de mecanografiado de mi proyecto cuando instalé la nueva versión de mecanografiado, pero parece que solo se actualizó <TypeScriptToolsVersion>2.2</TypeScriptToolsVersion> . ¿No debería actualizar también los paquetes nuget?

Acabo de actualizar a Typecript 2.2.1 y tengo el mismo problema. Está marcando todos los node_modules pero el compilador tsc se completa sin problemas.

@mhegazy

@Hotell no veo esto localmente, ¿qué me estoy perdiendo?

correcto, fue solucionado por https://github.com/wc-catalogue/blaze-elements/commit/cdb94bf8feb3a1ad7e21e6fce243e3322c1334cc

¡Solicite una respuesta tardía y gracias 4!

@Hotell @mhegazy No parece funcionar para mí.
¿Quizás funcione si tiene archivos d.ts en una carpeta de "definiciones"?
Pero yo no tengo eso. Tengo @types en "node_modules" que deberían excluirse por herencia.

@chrismbarr ¿ Puedo preguntar si ya resolvió esto? He estado siguiendo el hilo e incluso hice la corrección sugerida por @Hotell en un par de publicaciones, pero todavía recibo estos errores en Visual Studios. Todos parecen provenir de la carpeta node_modules.

¿Podría habilitar el registro detallado y enviarnos los resultados? Establezca la variable de entorno del sistema TSS_LOG en un valor como -file C:/temp/logs/tsserver.log -level verbose (asegúrese de que exista la carpeta de registros). Luego, después de reprogramar el problema, envíe / adjunte el registro para su análisis. (Nota: puede contener datos como rutas de archivo y listas de finalización, así que asegúrese de que no haya ningún dato que no desee compartir).

En mis pruebas, he visto ocasionalmente que el sistema de proyectos construye una vista del proyecto que contiene los archivos incorrectos, lo que provoca errores intermitentes en momentos impredecibles. Me gustaría ver si esa puede ser la causa aquí.

Puedo proporcionar mi dirección de correo electrónico si prefiere enviar los archivos directamente en lugar de cargarlos (billti en microsoft dot com). Gracias.

@johnlee no, sigue igual en VS2015. Sin embargo, desde entonces comencé a usar Visual Studio 2017 y no tengo errores allí.

@billti Variable agregada, visual studio (2017) reiniciado, solución reconstruida, pero el archivo de registro no se está creando. ¿Qué debo comprobar?

¿Es definitivamente una variable de entorno del sistema (es decir, si abre un nuevo símbolo del sistema y ejecuta SET TSS aparece la configuración)? Si no es así, ¿la carpeta en la que se va a escribir el registro ya está presente (el registrador no creará directorios que no existan)? Aparte de eso, también es más seguro usar barras diagonales en lugar de barras invertidas en la ruta.

:(

@billti Ok, acabo de comprobar y los archivos de registro están ahí ahora. Encuéntrelos aquí adjuntos
tss-log.zip

Gracias. Eché un vistazo a ese registro y no veo que ninguna llamada en él informe ese error. ¿El error ocurrió definitivamente en el período de tiempo que cubre este registro?

@billti Sí, los errores están ocurriendo en todo momento:

Simplemente están ahí permanentemente. Y actualizado en cada construcción.

Todos esos errores relacionados con declaraciones de variables incorrectas (un problema separado que ya hemos solucionado para una próxima versión). Este problema es de aproximadamente Cannot write file... según el título y las capturas de pantalla anteriores. ¿No tienes el problema Cannot write file... ?

@billti después de publicar mi mensaje anterior (que dejé allí como demostración de mi estupidez) me di cuenta de que los errores son de otro tipo. Solo puedo adivinar que la actualización de Visual Studio que instalé hace unos días resolvió el problema original. Pero no estoy seguro.
Me deshice de estos errores del mensaje anterior simplemente eliminando los tipos de @types.
Muchas gracias.

@billti Estoy tratando de tener algunos registros para enviarte, pero no se crea ninguno. He establecido TSS_LOG en -file C:/temp/logs/tsserver.log -level verbose en las variables de mi sistema (no de usuario).

C:\temp\logs existe, y le di el control total a Everyone .

Si reinicio mi VS2015, no se crea nada dentro de C:\temp\logs incluso después de recibir todos mis errores Cannot write file... . Si intento escribir node node_modules\typescript\lib\tsserver.js (y CTRL + C inmediatamente) en un nuevo símbolo del sistema, obtengo dos archivos de registro.

Lo siento @kevindqc , no me di cuenta de que estabas en VS 2015. Ese registro solo se aplica a VS 2017 (que ahora usa tsserver.js fuera de proceso para el servicio de idioma).

Volviendo atrás y mirando su problema, si ve que la lista de errores cambia aleatoriamente, creo que es el mismo problema que @zhengbli acaba de solucionar en https://github.com/Microsoft/TypeScript/pull/15080 .

@billti np. Creo que este problema solo está ocurriendo en VS2015, ¿no? El único usuario con el problema que estaba usando VS2017 tenía diferentes errores relacionados con la mecanografía. Alguien que cambió de VS2015 a VS2017 dijo que el problema desapareció.

Además, la lista de errores no cambia aleatoriamente, se completa en un momento aleatorio, una vez, con todos esos errores de "No se puede escribir ..." de los que trata este problema. ¿Estás seguro de que el # 15080 lo soluciona? No veo nada sobre este problema, excepto la referencia que hizo ayer. ¿Cómo puedo probarlo? Veo que hay un 2.3 RC, pero se lanzó hace 9 días, mientras que la solución se fusionó hace 2 días :(

También noté que los errores permanecen en mi lista de errores incluso después de cerrar la solución.

Además, la persona que publicó su proyecto virtual mecanografiado era la que tenía los diferentes errores, así que imagino que no fue útil. Aquí esta el mio:

¿Se supone que node_modules debe estar allí? Está en mi tsconfig excluye. Sin embargo, no contiene todo lo que tiene mi carpeta física node_modules (14 subcarpetas frente a 854 subcarpetas en mi carpeta 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
  }
}

Hasta ahora no he tenido los errores después de actualizar a las herramientas TS2.3. ¡Gracias!
Editar: Nop. Después de todo, los errores siguen ahí, solo tardaron más en aparecer.

Parece que este problema está relacionado con este problema . Solución de muestra para reproducir - cargada.

Encontré una solución para mí. En mi caso, usé outDir y rootDir sin especificar la matriz files . Al agregar la ruta de outDir a la matriz exclude todo parece funcionar normalmente.

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

Tal vez TypeScript también esté vigilando el contenido de la carpeta dist aunque esté configurado como outDir .

Si tiene su outDir debajo de la raíz de su proyecto, y solo está incluyendo todo debajo de la raíz, entonces es de esperar. Por lo general, desea tener la salida de la compilación en otro lugar que no sea la carpeta de origen del proyecto.

Parece que todos los problemas anteriores se abordan en este hilo o problemas vinculados. Avísame si ese no es el caso y reabriré. ¡Gracias!

@billti ¿Asumo que su comentario es en respuesta a mi comentario anterior? Si es así, gracias por aclarar. Esto hace que el asunto sea más obvio para mí ahora, como asumí al especificar rootDir el compilador solo observará esa carpeta en particular y excluirá todo lo demás. Pero el comportamiento actual tiene sentido.

la mejor solución es de borislemke .
{ "compilerOptions": { ..., "outDir": "./dist", "rootDir": "./src", }, "exclude": [ "node_modules", "dist" <-- I had to add this to fix the errors ] }

Me encontré con el mismo problema y descubrí que una de mis importaciones hacía referencia incorrectamente a la clase en mi carpeta dist EG
importar {ClassName} desde "../../dist/ClassName";

Como la clase de importación estaba en la misma carpeta, la cambié a:
importar {ClassName} de "./ClassName";

y todo se vuelve a compilar :)

Teníamos una carpeta 'dist' predefinida en nuestra aplicación. Eliminar eso me lo arregló.

Creo que este es el problema subyacente (la última actualización de Windows Creators):
visual-studio-2015-elimina-file-on-save-cordova-solution

Simplemente agregue su carpeta "dist" a la lista de exclusiones en tsconfig.json
ex:
"excluir": ["módulos_nodo", "dist"]

Corregí esto agregando una sección Incluir:

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

También encontré esto cuando usé un outDir que estaba debajo de mi directorio de fuentes.

¿Cómo es que el compilador de mecanografiado no sabe por defecto que no debería intentar compilar cosas en el outDir ? Eso parece extraño. Sin embargo, agregar el outdir a la lista de exclusión lo solucionó.

tengo este problema con netbeans lol 👎

También recibí este error cuando tenía dos archivos foo.ts y foo.tsx , los cuales se compilarían en foo.js , obviamente.

  "compilerOptions": {
    "noEmit": true 
  }

Me lo arregló.

noEmit es una mejor solución si desea han generado *.js archivos a analizar. Después de todo, no se generan necesariamente con tsc .

En mi caso, Ream.js genera .ream/**.js que luego importo con import XXX from '#out/yyy' en mi código (que funciona, pero genera la advertencia "No se puede escribir el archivo ..." en VS Code).

Básicamente, la única razón para tener "noEmit": false es cuando usa tsc procesar. Para todos los demás entornos ( ts-node / ts-node-dev , paquete web, resumen) es más seguro habilitarlo.

Como @uglycoyote, lo que funcionó para mí fue agregar outdir a la matriz de exclusiones. Ninguna de las otras sugerencias funcionó.

Siento que este problema está relacionado con estos:

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

El problema me está sucediendo porque configuré "declaration": true en tsconfig.json , por lo que se enoja por los archivos d.ts en la carpeta de compilación, aunque el directorio está fuera del raíz. Puedo hacer una compilación nueva sin problemas, pero cualquier compilación posterior arrojará: Cannot write file ... because it would overwrite input file. . Por lo que pude ver en las otras historias, esto solía funcionar en otra versión, entonces algo debe haber cambiado.

Al igual que solucioné los problemas de que mis archivos test.ts estaban fuera de rootDir , tuve que agregar lo siguiente a tsconfig.json .

"exclude:" [ "./build" ]

Esto también puede suceder con la herencia de configuración. Cada configuración deberá especificar outDir separado. Parece que la ruta en outDir se resuelve en términos absolutos. Incluso podría ser un error desde el punto de vista del usuario.

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

Vale la pena verificar también si tiene una referencia errante dentro de package.json al "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"
  }

Experimenté esto en un proyecto con referencias de proyectos. Ninguna de las exclusiones importaba, lo que sí importaba era la entrada typings insinuada por @elmpp.

Entonces esto producirá TS5055: Cannot write file because it would overwrite input file en un proyecto con referencias a monorepo:

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

pero esto no reportará errores:

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

Entonces, evidentemente, tendré que manipular esta prepublicación o publicar el src en el paquete.

Configuración:

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

me lo arregló (mi outputDir era dist ).

Podría ser increíble si el directorio de salida se excluye de forma predeterminada para tsc --watch .

Para referencia futura, esto sucede si importa un módulo desde dentro.

Entonces, hacer import x from 'mymodule cuando esté dentro de mymodule activará esto. ¡Es muy críptico y probablemente debería arreglarse!

De manera similar, encontré el problema si tiene un index.ts con un montón de líneas como export * from './foo' , y en uno de esos archivos, estaba importando con import foo from '.' lugar de import foo from './foo' en uno de esos archivos exportados.

Me golpeé la cabeza con esto durante los últimos dos días hasta que eliminé index.ts y tuve un error de importación. Fue muy no obvio.

Entonces creo que el problema fue porque tengo 2 proyectos ts en el mismo repositorio. (Angular y Nestjs), el tsconfig.json de la carpeta de nivel 1 arroja este error. Lo arreglé poniendo exclude "public", que en público es mío, los códigos angulares con su propio tsconfig.json.

Tenía este problema porque no estaba seguro de por qué ts-node no funcionaba, entonces tsc para verificar si el problema era TypeScript. Como resultado de tsc , ahora tenía docenas de .js archivos al lado del ts que pude confirmar ejecutando git status

La solución fue git clean -f .

En mi caso, parece que VS Code había importado automáticamente un archivo de la carpeta dist lugar de la carpeta src . Arreglar eso resolvió el problema.

Esto realmente no debería estar cerrado, el mecanografiado debería imprimir un error que le indique lo que está sucediendo. Es casi imposible averiguarlo actualmente. No estoy seguro de qué lo causa de vez en cuando, VSCode tal vez actualice las referencias de tsconfig.json accidentalmente, pero ralentiza todo mucho y cada vez no ha sido trivial de depurar.

en el proyecto Vue, en la raíz, esto funcionó para mí:

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

Después de que agregué el
"outDir": "",
el problema se había ido.

Mi objetivo aquí es hacer que ts intellisence funcione en archivos .js / vue.

Tenía el mismo mensaje de error. El problema era que tenía dos archivos con el mismo nombre pero con una extensión diferente en la misma carpeta, por lo que eliminar el que tenía la extensión .js solucionó eso.

Tenía el mismo mensaje de error. El problema era que tenía dos archivos con el mismo nombre pero con una extensión diferente en la misma carpeta, por lo que eliminar el que tenía la extensión .js solucionó eso.

Sí, tuve el mismo problema. Cambié el nombre de un archivo .tsx .ts que VS-Code recreó amablemente, lo que provocó el problema.

No estoy seguro de cómo resolver esto correctamente, pero en mi caso, acabo de eliminar "declaration": true de tsconfig.json. Los archivos D.ts no se producen, pero de todos modos no los necesito.

Para cualquiera que haya venido aquí buscando en Google un mensaje de error similar, permítanme compartir mis hallazgos:

1. Como puede leer, este error se debió a que el compilador de TypeScript intentaba compilar un archivo .js en la misma ruta.
2. Lo más probable es que no desee compilar archivos .js en absoluto. Si es posible, elimine allowJs: true de su tsconfig.json o --allow-js de sus opciones de CLI.
3. En caso de que definitivamente los necesite, es posible que desee excluir de la compilación los archivos que se mencionaron en el mensaje de error. Algunas personas en este hilo han hecho eso (tal vez sin darse cuenta) agregando exclude: ... .
   
   
   
   • Tenga cuidado de no agregar 'excluir' debajo de compilerOptions .
   
   

Espero que ayude 🙏

Necesitaba excluir manualmente mi directorio de compilación lib/

Parece haber un error en alguna parte que hace que algunas opciones sean incompatibles. Descubrí que usando
allowJS true +
rootDir + outDir : OK
rootDir + outFile : NOK: rootDir no se tienen en cuenta: todos los archivos en dir y subdir están configurados para ser compilados y potencialmente sobrescritos.
algunas otras combinaciones de opciones están prohibidas.

"allowJs": true
"noEmit": true
trabaja para mi.

en el proyecto Vue, en la raíz, esto funcionó para mí:

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

Después de que agregué el
"outDir": "",
el problema se había ido.

Mi objetivo aquí es hacer que ts intellisence funcione en archivos .js / vue.

gracias, funciona para mí.

Si está usando TS solo para verificación de tipos SOLAMENTE (sin compilación) y lo necesita en archivos .js , use la solución @ guaizi149 :

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

Esto le dirá a TS que no debe preocuparse por la compilación, por lo tanto, no se sobrescribirá ningún archivo y no se activará ninguna advertencia. Esta es una mejor solución para usar outDir: "" .

Esto también puede suceder con la herencia de configuración. Cada configuración deberá especificar outDir separado. Parece que la ruta en outDir se resuelve en términos absolutos. Incluso podría ser un error desde el punto de vista del usuario.

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

¡Esta solución funcionó a las mil maravillas para mí! Mi tsconfig.json ve así ahora:

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

"allowJs": true
"noEmit": true
trabaja para mi.

Gracias @ guaizi149 , tu solución funciona para mí 👍

Resuelto: había incluido el directorio dist en mi compilación tsc:

"exclude": [
    "node_modules"
  ]

--- va a

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

¿Es dist su carpeta de compilación?

Si excluir outDir no funcionó para usted, intente verificar si tiene archivos duplicados con la misma ruta y nombre de archivo pero con diferentes extensiones.

Esto sucede cuando los archivos de declaración no se excluyen de la compilación. Siempre que esto ocurre, el constructor intenta construir los archivos ".d.ts" existentes y reemplazarlos con el mismo nombre de archivo. Entonces, es por eso que obtendrá el error: Cannot write file ... because it would overwrite input file.

Para evitar esto, puede excluir su "outDir":"build" en el archivo jour tsconfig.json:

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

o si no tiene outDir definido, excluya todos los d.ts . archivos de extensión:

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

Espero que esto ayude

@Abadii : tal vez sea porque estoy usando la opción -b mientras compilo, pero ninguno de esos enfoques funcionó.

@Abadii : tal vez sea porque estoy usando la opción -b mientras compilo, pero ninguno de esos enfoques funcionó.

¿Puedes compartir tu archivo tsconfig.json y qué versión es tu tsc ?

@Abadii : Aquí está (sin la exclusión actualizada obviamente). La versión de tsc es 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 : Aquí está (sin la exclusión actualizada obviamente). La versión de tsc es 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, eche un vistazo al siguiente repositorio. He usado su tsconfig.json para regenerar el error:

https://github.com/Abadii/tsconfig

PD: ¿Y qué pasará cuando elimines tu carpeta ../lib? ¿Construirá?

@Abadii : Se compilará si solo se compilará si elimino / vacío la carpeta de compilación). Esto es cierto incluso si exclude archivos de declaración y la carpeta de compilación.
Para su información, la estructura del proyecto es así:

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

y construyo con: tsc -p ./src/tsconfig.json
(en realidad, generalmente construyo con rm -rf ./lib && tsc -p src/tsconfig.json pero eso es lo que estoy aquí para arreglar;))

@Abadii : Se compilará si solo se compilará si elimino / vacío la carpeta de compilación). Esto es cierto incluso si exclude archivos de declaración y la carpeta de compilación.

Entonces, ahora sabe que la carpeta de compilación está causando el problema. De alguna manera, su compilación tsc no excluye su carpeta de compilación. Puede intentar utilizar la ruta absoluta en la exclusión.
También he notado que su carpeta de compilación está fuera de su alcance ../lib . Quizás esa sea también la razón por la que no excluye. Pruebe ./lib como outDir para comprobar si cambia el comportamiento
Si es un usuario de Windows, verifique que la ruta absoluta definida sea correcta.

@Abadii : Gracias, pero no puedo usar rutas absolutas ya que trabajo en el proyecto en varias máquinas y no puedo garantizar una estructura de carpetas idéntica en todas ellas. Para mí, esto parece un error: le digo a tsconfig que excluya tanto la carpeta como los archivos de declaración, pero no es así. ¿Debería reabrirse?

@Abadii : Gracias, pero no puedo usar rutas absolutas ya que trabajo en el proyecto en varias máquinas y no puedo garantizar una estructura de carpetas idéntica en todas ellas. Para mí, esto parece un error: le digo a tsconfig que excluya tanto la carpeta como los archivos de declaración, pero no es así. ¿Debería reabrirse?

Ya veo, tal vez lo último que pueda intentar es poner su archivo tsconfig en project/tsconfig.json y cambiar las rutas. También estoy sin opciones si eso no funciona, supongo.

Intentó:

1. Configurando outDir -> no.
2. Configurando allowJs: false -> no.
3. Excluyendo .d.ts -> no.
4. noEmit: true -> no.

He probado todas las sugerencias de este hilo. El error VSCode no solo persiste, sino que se refiere a un archivo que ya no existe. 🤷‍♂️

Intentó:

1. Configurando outDir -> no.
2. Configurando allowJs: false -> no.
3. Excluyendo .d.ts -> no.
4. noEmit: true -> no.

He probado todas las sugerencias de este hilo. El error VSCode no solo persiste, sino que se refiere a un archivo que ya no existe.

¿Qué sucede cuando intentas construir directamente a través de la terminal?

Establezca un outDir y asegúrese de que esté vacío antes de construir

@Abadii Entonces .... parece que la razón por la que esto estaba sucediendo era que, aunque los archivos JS no estaban incluidos, estaban fallando porque eran módulos CommonJS .... 🤔 ....

En otras palabras, una vez que todo tuvo importaciones / exportaciones adecuadas, dejé de tener este problema. Entonces, según los comentarios de este hilo y la gran cantidad de correcciones, creo que este es uno de esos errores de pista falsa. Como en, cuando hay un tipo X de JS / Intellisense / problema de compilación, VSCode arroja este error Cannot write file . Pero, en mi caso, esto se resolvió con una solución DIFERENTE a cualquier otra de las numerosas soluciones ofrecidas en este hilo. 🤷‍♂️ Y nuevamente, arrojó este error en un archivo que _no existía_ y _no sería reemplazado_. Entonces, ¿tal vez los errores se están almacenando en caché y un error desconocido arroja un error en caché? ¿Algo como eso? Creo que alguien necesita inspeccionar el código en torno a este error en particular.

Comentando aquí porque es lo primero que surgió en mi búsqueda de google.

También me encontré con este problema. Parece que alguna parte del proceso de compilación no reconoce que está dentro de un directorio excluido.

No veo el problema si hago esto:

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

Veo el problema si hago esto:

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

o esto:

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

El error ocurre a pesar de que los archivos de los que se queja están 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.

En mi caso, tengo las importaciones configuradas donde src/index.ts importa y reexporta desde src/matchers/index.ts que a su vez importa y reexporta desde src/matchers/eitherMatchers/index.ts .

Los dos primeros archivos son los que causan los errores de compilación. El tercer archivo está bien. Por lo tanto, parece que podría estar relacionado con la forma en que el árbol de importación / exportación está afectando la compilación.

Me encontré con este problema mientras tenía el mismo problema, y ​​pensé en agregar lo que resultó ser el mío en caso de que otras personas lo encuentren de la misma manera.

En mi caso, tengo un monorepo con un archivo tsconfig separado para cada paquete, que se extienden desde un tsconfig base. Cada configuración de paquetes tiene entradas references que apuntan a la ruta de los paquetes de los que depende. También tengo un tsconfig.json en la raíz del repositorio que incluye files: [] y tiene referencias a todos los directorios del paquete. De esta manera puedo ejecutar tsc -b --watch desde la raíz y hacer que se reconstruya con los cambios a lo largo de todo el proyecto.

Esto funcionó bien durante bastante tiempo, luego repentinamente comenzó a arrojar este error a pesar de que ninguna de las configuraciones había cambiado.

Finalmente lo rastreé al intentar compilar el único paquete que se informaba en el error por sí mismo, en lugar de compilar todo el proyecto.

Resulta que el problema era que había intentado que el proyecto se importara. El nombre del paquete era @my-project/utils , y funcionó bien hasta que moví un código de otro paquete a un archivo en el paquete utils. Ese código incluía import stuff from '@my-project/utils'; y eso fue lo que causó el error. Al cambiar a import stuff from '.'; en su lugar, el error desapareció.

@jasonk Esto probablemente solo esté revelando mi ignorancia, pero ¿no funcionaría eso solo si su monorepo está agrupado por algo que resolverá todas esas importaciones (por ejemplo, paquete web)? Si su monorepo está compuesto por módulos que se pueden publicar y usar de forma independiente, cambiar a importaciones relativas causaría errores, ¿no?

@Ghirigoro No, el problema no era que estaba usando una ruta de paquete, es que estaba usando una ruta de paquete para importar un paquete desde dentro. Incluso sin Typecript, eso no funcionará.

Básicamente, lo que había hecho era el equivalente a esto:

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

Si luego intentas ejecutar eso con el nodo:

$ 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: []
}

Si reemplaza el nombre del paquete, entonces funciona correctamente:

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

Sospecho que lo que sucedió fue que cuando se ejecutó la compilación, todos los demás paquetes que se estaban importando desde @my-project/utils tenían esa importación resuelta en packages/utils (porque tenían las entradas correctas en references array en tsconfig), por lo que se construyeron normalmente. Pero debido a que se suponía que ese paquete no se importaría solo, la importación se resolvió en node_modules/@my-project/utils , que era un enlace simbólico a packages/utils , pero TypeScript no detectó que en realidad eran el mismo proyecto, así que intentó compilarlo dos veces, pero como ambas compilaciones tenían el mismo directorio de salida, terminé con este error.

Esto sucede cuando los archivos de declaración no se excluyen de la compilación. Siempre que esto ocurre, el constructor intenta construir los archivos ".d.ts" existentes y reemplazarlos con el mismo nombre de archivo. Entonces, es por eso que obtendrá el error: Cannot write file ... because it would overwrite input file.

Para evitar esto, puede excluir su "outDir":"build" en el archivo jour tsconfig.json:

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

o si no tiene outDir definido, excluya todos los d.ts . archivos de extensión:

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

Espero que esto ayude

Excluir mi directorio de compilación resolvió el problema por mí

Lo más probable es que esto suceda cuando intentas ejecutar un proyecto con dos nodos.
Para esta hipótesis, puede probar el recuento de procesos en su computadora denominada "nodo" después de ejecutar la compilación.
Qué hice para resolver el problema:
Paso 1.
Comparar
node -v
y
nvm -ls , la versión en uso.
En el terminal, configure la versión actual del nodo:
nvm use {neededVersion}
En principio, elimine las versiones innecesarias del nodo en nvm (esto ayudará a su IDE a determinar automáticamente la versión normal del nodo).
Paso 2.
Determine el nodo actual en su IDE. es decir, en WebStorm:
Preferencias-> Idiomas y marcos -> Node.js y NPM: intérprete de nodo: configure la versión necesaria.
(Además, puede verificar la versión del nodo para cada elemento en todas partes (mecanografiado))

Además, este problema puede ocurrir si los paquetes npm o los submódulos git usaron su propio nodo dentro

Estaba enfrentando este problema para el proyecto Webdriver IO / WDIO. Se resolvió cuando eliminé "wdio.config.js" de "incluir" en tsconfig.json.