Typescript: Erreur "Impossible d'écrire le fichier... car cela écraserait le fichier d'entrée."

J'ai aussi le même problème.

--allowjs défini ? pouvez-vous partager le projet?

Désolé, je ne peux pas partager le projet, et non, ce drapeau n'est pas défini. Mon tsconfig.json est au-dessus, et nous l'utilisons simplement avec VS2015 Update 3, qui déclenche simplement la construction avec MSBuild normalement.

J'ai des coéquipiers qui se plaignent du même problème qui leur arrive sur les mêmes projets. Je travaille également sur un projet à la maison sur un autre ordinateur qui a exactement le même problème et la même configuration (TS 2.2.1, VS2015 U3, etc.)

voyez-vous le même comportement si vous créez un projet simple avec les mêmes configurations ?

Nous avons le même problème https://github.com/wc-catalogue/blaze-elements/issues/299 bien qu'avec les définitions de type accès en écriture

@Hotell voyez -vous cela sans "awesome-typescript-loader" ? pouvez-vous partager les étapes de repro avec moi ?

oui, comme vous pouvez le voir dans le problème, la sortie provient de l'exécution brute de tsc deuxième fois.

il suffit de cloner le repo https://github.com/wc-catalogue/blaze-elements

• appuyez sur yarn depuis la racine
• appuyez sur yarn tsc -> première compilation (tout va bien) => première fois definitions/ dossier généré
• appuyez à nouveau sur yarn tsc -> erreurs

Nous avons un problème similaire -- même version de typescript (2.2.1) et Visual Studio 2015 (Mise à jour 3) ; la première fois que la construction s'exécute, il n'y a aucune erreur, mais après cela, nous obtenons des centaines de ces erreurs.

Il semble que toutes les erreurs (pour nous) se trouvent dans le dossier "node_modules", que nous avons défini pour exclure dans notre fichier tsconfig.json. -- En examinant des bogues similaires, il semble que les exclusions ne soient pas traitées de la même manière dans cette version de tapuscrit ?

Notre fichier 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
}

Certaines des erreurs que nous obtenons (ce sont toutes les mêmes, mais des fichiers différents) :

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

Encore une fois, si nous supprimons le dossier "node_modules", la construction fonctionnera une fois, mais une fois recréée, elle échouera lors de la prochaine reconstruction.

@Hotell, je ne vois pas cela localement, qu'est-ce que je manque ?

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 vous avez un projet de repro, j'aimerais y jeter un œil.

Je suis également confronté au même problème, voici les erreurs:

Et voici mon tsconfig.json :

Comme je n'utilise pas du tout de typescript, je viens de créer tsconfig pour ignorer la construction, j'ai également dû choisir target=ES6 sinon j'avais d'autres erreurs.

le tsconfig.json fait-il partie de votre projet ? et pouvez-vous confirmer que le type de contenu est « Contenu » ? si oui, pouvez-vous partager votre projet ?

@mhegazy Salut, oui je peux confirmer que tsconfig.json est inclus dans le projet :

Mais je suis désolé, je ne sais pas à quel "type de contenu" faites-vous référence, pouvez-vous clarifier s'il vous plaît ?

Je ne peux pas partager le projet.

Sur mon projet, je peux également confirmer que le fichier tsconfig est inclus dans le fichier projet et qu'il est répertorié comme contenu.

@max-favilli Je pense que @mhegazy signifie "l'action de construction" lorsque l'on parle de "type de contenu".

Sélectionnez tsconfig.json dans l'explorateur de solutions. Affichez la fenêtre Propriétés (touche F4 par défaut). Il y aura une propriété Build Action.

Merci @kevindqc , @mhegazy oui "Build Action" est défini sur "content"

Pouvez-vous partager la structure de votre projet virtuel avec moi, pour l'obtenir, vous devez :

• allez à Tools > Options > Text Editor > TypeScript > Project , et cochez Display Virtual Projects when no Solution is loaded ;
• redémarrez VS et ouvrez un fichier dans votre projet
• vous devriez maintenant voir un nouveau nœud dans votre explorateur de solutions sous le nom de TypeScript Virtual Project

@mhegazy comme ça ?

Merci pour ton aide.

J'ai le même problème. Je ne peux pas non plus partager le projet, mais je vais essayer de fournir le plus d'informations possible.

J'ai désactivé la compilation de scripts dans le fichier .csproj ( <TypeScriptCompileBlocked>true</TypeScriptCompileBlocked> )
Au lieu de cela, il est compilé par npm run build:prod , qui se trouve dans un événement de génération.

Les erreurs ne sont pas toujours là. J'ai essayé de les faire apparaître (ils ont été affichés dans VS, j'ai donc redémarré VS). J'ai essayé de créer le projet dactylographié, de créer la solution, d'exécuter des tests, d'exécuter une analyse de code, d'exécuter une couverture de code, etc. Rien ne le déclenche. Puis, juste au moment où j'écrivais la dernière phrase, les erreurs sont apparues. Il semble donc que ce soient des tâches d'arrière-plan qui le font ? Cela semble se produire environ 2 minutes après avoir commencé une construction (au moins les 2-3 fois où je l'ai essayé)

Chronologie:
1:37:20 - Ouverture de Visual Studio
1:37:30 - Création de la solution commencée
1:38:20 - Construction terminée
1:39:39 - Des erreurs sont apparues

J'ai remarqué que mon projet utilisait toujours les packages v2.0.3 Microsoft.TypeScript.Compiler et Microsoft.TypeScript.MSBuild nuget. Je les ai mis à jour en v2.2.1. Pour l'instant, aucune erreur. Mettra à jour si je vois à nouveau les erreurs. (Edit : je vois à nouveau les erreurs, même si cela a pris un peu plus de temps, environ 5 minutes, sans que je fasse autre chose que de construire lorsque j'ai ouvert VS. En fait, je n'ai même pas besoin de construire quoi que ce soit pour obtenir l'erreur - il suffit d'ouvrir le projet et attendre quelques minutes montre les erreurs)

À propos de ces paquets nuget obsolètes, est-ce normal ? Je pense que j'ai obtenu une fenêtre contextuelle pour mettre à niveau mes outils de saisie de projet lorsque j'ai installé la nouvelle version de saisie, mais il semble qu'elle n'ait mis <TypeScriptToolsVersion>2.2</TypeScriptToolsVersion> jour que

Je viens de mettre à jour vers Typescript 2.2.1 et j'ai le même problème. Il signale tous les node_modules mais le compilateur tsc se termine sans problème.

@mhegazy

@Hotell, je ne vois pas cela localement, qu'est-ce que je manque ?

à droite, il a été corrigé par https://github.com/wc-catalogue/blaze-elements/commit/cdb94bf8feb3a1ad7e21e6fce243e3322c1334cc

sry pour la réponse tardive et merci 4 aide!

@Hotell @mhegazy Ne semble pas fonctionner pour moi.
Peut-être que cela fonctionne si vous avez des fichiers d.ts dans un dossier « définitions » ?
Mais je n'ai pas ça. J'ai des @types sous "node_modules" qui devraient être exclus par héritage ?

@chrismbarr Puis-je vous demander si vous avez déjà résolu ce @Hotell quelques messages, mais je reçois toujours ces erreurs dans Visual Studios. Ils semblent tous provenir du dossier node_modules.

Pourriez-vous activer la journalisation détaillée et nous envoyer les résultats ? Définissez la variable d'environnement système TSS_LOG sur une valeur telle que -file C:/temp/logs/tsserver.log -level verbose (assurez-vous que le dossier des journaux existe). Ensuite, après avoir reproduit le problème, envoyez/joignez le journal pour analyse. (Remarque : il peut contenir des données telles que des chemins de fichiers et des listes d'achèvement, alors assurez-vous qu'il n'y a pas de données que vous ne souhaitez pas partager).

Lors de mes tests, j'ai parfois vu le système de projet construire une vue du projet contenant les mauvais fichiers, provoquant des erreurs intermittentes à des moments imprévisibles. J'aimerais voir si cela peut être la cause ici.

Je peux fournir mon adresse e-mail si vous préférez envoyer les fichiers directement plutôt que de les télécharger (billti chez microsoft dot com). Merci.

@johnlee non, toujours le même dans VS2015. Cependant, j'ai depuis commencé à utiliser Visual Studio 2017 et je n'ai aucune erreur là-dedans !

@billti Variable ajoutée, visual studio (2017) redémarré, solution reconstruite, mais le fichier journal n'est pas créé. Que dois-je vérifier ?

Est-ce vraiment une variable d'environnement système (c'est-à-dire si vous ouvrez une nouvelle invite de commande et exécutez SET TSS le paramètre est-il répertorié) ? Si ce n'est pas le cas, le dossier dans lequel le journal doit être écrit est-il déjà présent (le logger ne créera pas de répertoires qui n'existent pas). En dehors de cela, il est également plus sûr d'utiliser des barres obliques plutôt que des barres obliques inverses dans le chemin.

:(

@billti Ok, je viens de vérifier et les fichiers journaux sont là maintenant. Veuillez les trouver ici ci-joint
tss-log.zip

Merci. J'ai jeté un œil à ce journal et je ne vois pas cette erreur signalée par les appels qu'il contient. L'erreur s'est-elle vraiment produite dans la période couverte par ce journal ?

@billti Oui, les erreurs se produisent à tout moment :

Ils sont juste là en permanence. Et actualisé sur chaque version.

Toutes ces erreurs liées à des déclarations de variables incorrectes (un problème distinct que nous avons déjà corrigé pour une prochaine version). Ce problème est d'environ Cannot write file... par le titre et les captures d'écran ci-dessus. Vous n'avez pas le problème Cannot write file... ?

@billti après avoir posté mon message précédent (que j'ai laissé là comme démonstration de ma stupidité), j'ai réalisé que les erreurs sont d'un autre genre. Je ne peux que deviner que la mise à jour de Visual Studio que j'ai installée il y a quelques jours a résolu le problème d'origine. Mais je ne suis pas sûr.
Je me suis débarrassé de ces erreurs du message précédent en supprimant simplement les types de @types.
Merci beaucoup.

@billti J'essaie d'avoir des journaux à vous envoyer, mais aucun n'est créé. J'ai défini TSS_LOG sur -file C:/temp/logs/tsserver.log -level verbose dans mes variables système (pas utilisateur).

C:\temp\logs existe, et j'ai donné le contrôle total à Everyone .

Si je redémarre mon VS2015, rien n'est créé dans C:\temp\logs même après avoir obtenu toutes mes erreurs Cannot write file... . Si j'essaie de taper node node_modules\typescript\lib\tsserver.js (et CTRL+C immédiatement) dans une nouvelle invite de commande, j'obtiens deux fichiers journaux.

Désolé @kevindqc , je ne savais pas que vous étiez sur VS 2015. Cette journalisation ne s'applique qu'à VS 2017 (qui utilise désormais tsserver.js hors processus pour le service de langue).

Pour revenir en arrière et examiner votre problème - si vous voyez la liste d'erreurs changer de manière aléatoire, je pense que c'est le même problème que @zhengbli vient de https://github.com/Microsoft/TypeScript/pull/15080 .

@billti np. Je pense que ce problème ne se produit que sur VS2015, non ? Le seul utilisateur avec le problème qui utilisait VS2017 avait différentes erreurs liées aux frappes. Quelqu'un qui est passé de VS2015 à VS2017 a déclaré que le problème avait disparu.

De plus, la liste d'erreurs ne change pas au hasard - elle est remplie à un moment aléatoire, une fois, avec toutes ces erreurs "Impossible d'écrire .." à propos de ce problème. Êtes-vous sûr que #15080 le résout ? Je ne vois rien à propos de ce problème à part la référence que vous y avez faite hier? Comment puis-je le tester? Je vois qu'il y a un 2.3 RC mais il a été publié il y a 9 jours alors que le correctif a été fusionné il y a 2 jours :(

De plus, j'ai remarqué que les erreurs restaient dans ma liste d'erreurs même après avoir fermé la solution.

De plus, la personne qui a posté son projet virtuel dactylographié était celle avec les différentes erreurs, donc j'imagine que cela n'a pas été utile. Voici le mien:

Est-ce que node_modules censé être là ? C'est dans mon tsconfig exclut. Il ne contient pas tout ce que mon dossier physique node_modules contient (14 sous-dossiers contre 854 sous-dossiers dans mon dossier 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
  }
}

Je n'ai pas eu d'erreurs jusqu'à présent après la mise à niveau vers les outils TS2.3. Merci!
Edit : Non. Les erreurs sont toujours là après tout, elles ont juste mis plus de temps à apparaître.

Il semble que ce problème soit lié à ce problème . Exemple de solution à reproduire - téléchargé.

J'ai trouvé une solution pour moi. Dans mon cas, j'ai utilisé outDir et rootDir sans spécifier le tableau files . Lors de l'ajout du chemin de outDir au tableau exclude , tout semble fonctionner normalement.

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

Peut-être que TypeScript surveille également le contenu du dossier dist même s'il est défini comme outDir .

Si vous avez votre outDir sous la racine de votre projet et que vous incluez simplement tout sous la racine, cela devrait être le cas. En général, vous souhaitez que votre sortie de build soit ailleurs que dans le dossier source du projet.

On dirait que tous les problèmes ci-dessus sont traités dans ce fil ou dans des problèmes liés. Faites-moi savoir si ce n'est pas le cas et je rouvrirai. Merci!

@billti Je suppose que votre commentaire est en réponse à mon commentaire précédent ? Si oui, merci d'avoir précisé. Cela rend la question plus évidente pour moi maintenant, car je suppose que lors de la spécification du rootDir le compilateur ne surveillera que ce dossier particulier et exclura tout le reste. Mais le comportement actuel est logique.

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

J'ai rencontré le même problème et j'ai découvert qu'une de mes importations faisait référence de manière incorrecte à la classe dans mon dossier dist EG
importer {ClassName} de "../../dist/ClassName" ;

Comme la classe d'importation était dans le même dossier, je l'ai changé en :
importer {ClassName} de "./ClassName" ;

et tout se compile à nouveau :)

Nous avions un dossier « dist » prédéfini dans notre application. Supprimer cela a résolu le problème pour moi.

Je pense que c'est le problème sous-jacent (la dernière mise à jour de Windows Creators) :
visual-studio-2015-supprime-fichier-sur-enregistrement-cordova-solution

Ajoutez simplement votre dossier "dist" à la liste des exclusions dans tsconfig.json
ex:
"exclude": ["node_modules", "dist"]

J'ai corrigé cela en ajoutant une section Inclure :

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

J'ai également rencontré cela lors de l'utilisation d'un outDir qui se trouvait dans mon répertoire de sources.

Comment se fait-il que le compilateur dactylographié ne sache pas par défaut qu'il ne doit pas essayer de compiler des choses dans le outDir ? Cela semble étrange. L'ajout de l'outdir à la liste d'exclusion l'a cependant corrigé.

j'ai ce problème avec netbeans lol

J'ai également eu cette erreur lorsque j'avais deux fichiers foo.ts et foo.tsx , qui seraient tous deux compilés en foo.js , évidemment.

  "compilerOptions": {
    "noEmit": true 
  }

C'est corrigé pour moi.

noEmit est une meilleure solution si vous ne voulez avoir généré *.js fichiers à analyser. Ils ne sont pas nécessairement générés avec tsc , après tout.

Dans mon cas, Ream.js génère .ream/**.js que j'importe ensuite avec import XXX from '#out/yyy' dans mon code (ce qui fonctionne, mais génère l'avertissement "Impossible d'écrire le fichier..." dans VS Code).

Fondamentalement, la seule raison d'avoir "noEmit": false est lorsque vous utilisez raw tsc . Pour tous les autres environnements ( ts-node / ts-node-dev , webpack, rollup), il est plus sûr de l'activer.

Comme @uglycoyote, ce qui a fonctionné pour moi a été d'ajouter le outdir au tableau d'exclusion. Aucune des autres suggestions n'a fonctionné.

J'ai l'impression que ce problème est lié à ceux-ci:

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

Le problème m'arrive parce que j'ai défini "declaration": true dans le tsconfig.json , donc il se met en colère contre les fichiers d.ts dans le dossier de construction, même si le répertoire est en dehors du racine. Je peux faire une nouvelle version sans problèmes, mais toute version ultérieure générera : Cannot write file ... because it would overwrite input file. . D'après ce que j'ai pu voir sur les autres histoires, cela fonctionnait dans une autre version, puis quelque chose a dû changer.

Tout comme j'ai résolu les problèmes concernant mes fichiers test.ts en dehors du rootDir j'ai dû ajouter ce qui suit au tsconfig.json .

"exclude:" [ "./build" ]

Cela peut également se produire avec l'héritage de configuration. Chaque configuration devra spécifier outDir séparément. Il semble que le chemin dans outDir soit résolu en termes absolus. Peut-être même un bug du point de vue de l'utilisateur.

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

Cela vaut également la peine de vérifier si vous avez une référence erronée dans package.json au "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"
  }

J'ai vécu cela dans un projet avec des références de projet. Aucune des exclusions n'avait d'importance, c'était l'entrée typings suggérée par @elmpp.

Cela produira donc TS5055: Cannot write file because it would overwrite input file dans un projet faisant référence au monorepo :

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

mais cela ne rapportera aucune erreur :

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

Donc, évidemment, je devrai soit manipuler cette prépublication, soit publier le src dans le package.

Réglage:

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

l'a corrigé pour moi (mon outputDir était dist ).

Cela pourrait être génial si le répertoire de sortie est exclu par défaut pour tsc --watch .

Pour référence future, cela se produit si vous importez un module à partir de lui-même.

Donc, faire import x from 'mymodule à l'intérieur de mymodule déclenchera cela. C'est très énigmatique et devrait probablement être corrigé !

De même, je rencontre le problème si vous avez un index.ts avec un tas de lignes comme export * from './foo' , et dans l'un de ces fichiers, j'importais avec import foo from '.' plutôt que import foo from './foo' dans l'un de ces fichiers exportés.

Je me suis cogné la tête dessus pendant les deux derniers jours jusqu'à ce que je supprime index.ts et que j'aie une erreur d'importation. C'était très peu évident.

Je pense donc que le problème vient du fait que j'ai 2 projets ts dans le même dépôt. ( Angular & Nestjs ) , le tsconfig.json du dossier de niveau 1 renvoie cette erreur. J'ai corrigé en mettant exclure "public" , qui en public est le mien des codes angulaires avec son propre tsconfig.json.

J'avais ce problème parce que je ne savais pas pourquoi ts-node ne fonctionnait pas, alors j'ai tsc pour vérifier si le problème était TypeScript. À la suite de tsc , j'avais maintenant des dizaines de fichiers .js côte à côte avec les ts que j'ai pu confirmer en exécutant git status

La solution était de git clean -f .

Dans mon cas, il semble que VS Code ait importé automatiquement un fichier du dossier dist au lieu du dossier src . La correction qui a résolu le problème.

Cela ne devrait vraiment pas être fermé, tapscript devrait imprimer une erreur vous indiquant ce qui se passe. C'est presque impossible à comprendre actuellement. Je ne sais pas ce qui le cause de temps en temps, VSCode peut mettre à jour les références tsconfig.json accidentellement, mais cela ralentit tout énormément et à chaque fois, il n'a pas été trivial de déboguer.

dans le projet Vue, à la racine, cela a fonctionné pour moi :

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

Après avoir ajouté le
"outDir": "",
le problème avait disparu.

Mon objectif ici est juste de faire fonctionner ts intelligence dans les fichiers .js/vue.

Avait le même message d'erreur. Le problème était que j'avais deux fichiers avec le même nom mais une extension différente dans le même dossier, donc la suppression de celui avec l'extension .js résolu le problème.

Avait le même message d'erreur. Le problème était que j'avais deux fichiers avec le même nom mais une extension différente dans le même dossier, donc la suppression de celui avec l'extension .js résolu le problème.

Oui j'ai eu le même problème. J'avais renommé un fichier .tsx .ts que VS-Code a recréé utilement, provoquant le problème.

Je ne sais pas comment résoudre ce problème correctement, mais dans mon cas, je viens de supprimer "declaration": true de tsconfig.json. Les fichiers D.ts ne sont pas produits, mais je n'en ai pas besoin de toute façon.

À quiconque est venu ici en cherchant sur Google un message d'erreur similaire, permettez-moi de partager mes conclusions :

1. Comme vous pouvez le lire, cette erreur est due au fait que le compilateur TypeScript tentait de compiler un fichier .js dans le même chemin.
2. Très probablement, vous ne voulez pas du tout compiler les fichiers .js. Si possible, supprimez allowJs: true de votre tsconfig.json ou --allow-js de vos options CLI.
3. Au cas où vous en auriez vraiment besoin, vous souhaiterez peut-être exclure de la compilation les fichiers mentionnés dans le message d'erreur. Certaines personnes dans ce fil l'ont fait (peut-être sans s'en rendre compte) en ajoutant exclude: ... .
   
   
   
   • Attention à ne pas ajouter 'exclude' sous le compilerOptions .
   
   

J'espère que ça aide

J'avais besoin d'exclure manuellement mon répertoire de construction lib/

Il semble y avoir un bug quelque part qui rend certaines options incompatibles. J'ai découvert qu'en utilisant
allowJS true +
rootDir + outDir : OK
rootDir + outFile : NOK : rootDir non pris en compte : tous les fichiers du répertoire et du sous-répertoire sont configurés pour être compilés et potentiellement écrasés.
certaines autres combinaisons d'options sont interdites.

"allowJs": true
"noEmit": true
travaille pour moi.

dans le projet Vue, à la racine, cela a fonctionné pour moi :

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

Après avoir ajouté le
"outDir": "",
le problème avait disparu.

Mon objectif ici est juste de faire fonctionner ts intelligence dans les fichiers .js/vue.

merci, ça marche pour moi.

Si vous utilisez TS uniquement pour la vérification de type UNIQUEMENT (pas de compilation) et que vous en avez besoin dans les fichiers .js , utilisez la solution @guaizi149 :

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

Cela indiquera à TS qu'il ne devrait pas s'inquiéter de la compilation, donc aucun fichier ne sera écrasé et aucun avertissement ne sera déclenché. C'est une meilleure solution pour utiliser outDir: "" .

Cela peut également se produire avec l'héritage de configuration. Chaque configuration devra spécifier outDir séparément. Il semble que le chemin dans outDir soit résolu en termes absolus. Peut-être même un bug du point de vue de l'utilisateur.

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

Cette solution a fonctionné comme un charme pour moi! Mon tsconfig.json ressemble à ceci maintenant :

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

"allowJs": true
"noEmit": true
travaille pour moi.

Merci @guaizi149 , votre solution fonctionne pour moi

Résolu - j'avais inclus le répertoire dist dans ma version tsc :

"exclude": [
    "node_modules"
  ]

--- va à

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

Est-ce que dist votre dossier de construction ?

Si l'exclusion de outDir n'a pas fonctionné pour vous, essayez de vérifier si vous avez des fichiers en double avec le même chemin et le même nom de fichier mais des extensions différentes.

Cela se produit lorsque les fichiers de déclaration ne sont pas exclus de la génération. Chaque fois que cela se produit, le générateur essaie de créer les fichiers ".d.ts" existants et de les remplacer par le même nom de fichier. C'est pourquoi vous obtiendrez l'erreur : Cannot write file ... because it would overwrite input file.

Pour éviter cela, vous pouvez exclure votre "outDir":"build" dans le fichier jour tsconfig.json :

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

ou si vous n'avez pas défini outDir, excluez tous les d.ts . fichiers d'extension :

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

J'espère que cela t'aides

@Abadii : c'est peut-être parce que j'utilise l'option -b lors de la compilation mais aucune de ces approches n'a fonctionné.

@Abadii : c'est peut-être parce que j'utilise l'option -b lors de la compilation mais aucune de ces approches n'a fonctionné.

Pouvez-vous partager votre fichier tsconfig.json et quelle est la version de votre tsc ?

@Abadii : Le voici (sans l'exclusion mise à jour évidemment). La version de tsc est la 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 : Le voici (sans l'exclusion mise à jour évidemment). La version de tsc est la 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"]
}

Veuillez consulter le dépôt suivant. J'ai utilisé votre tsconfig.json pour régénérer l'erreur :

https://github.com/Abadii/tsconfig

PS Et que se passera-t-il lorsque vous supprimerez votre dossier ../lib ? va-t-il se construire ?

@Abadii : Il sera construit si je supprime le dossier de construction (en fait, il ne sera construit que si je supprime/vide le dossier de construction). Cela est vrai même si je exclude fichiers de déclaration et le dossier de construction.
Pour info, la structure du projet est la suivante :

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

et je construis avec : tsc -p ./src/tsconfig.json
(en fait généralement je construis avec rm -rf ./lib && tsc -p src/tsconfig.json mais c'est ce que je suis ici pour corriger ;) )

@Abadii : Il sera construit si je supprime le dossier de construction (en fait, il ne sera construit que si je supprime/vide le dossier de construction). Cela est vrai même si je exclude fichiers de déclaration et le dossier de construction.

Alors maintenant, vous savez que le dossier de construction est à l'origine du problème. D'une manière ou d'une autre, votre construction tsc n'exclut pas votre dossier de construction. Vous pouvez essayer d'utiliser le chemin absolu dans l'exclusion.
J'ai également noté que votre dossier de construction est en dehors de votre portée ../lib . C'est peut-être aussi la raison pour laquelle il n'exclut pas. Essayez ./lib comme outDir pour vérifier si cela change le comportement
Si vous êtes un utilisateur Windows, vérifiez que le chemin absolu défini est correct.

@Abadii : Merci mais je ne peux pas utiliser de chemins absolus car je travaille sur le projet sur plusieurs machines et je ne peux pas garantir une structure de dossiers identique sur chacun d'eux. Pour moi, cela semble être un bogue - je dis à tsconfig d'exclure à la fois le dossier et les fichiers de déclaration, mais ce n'est pas le cas. Faut-il rouvrir celui-ci ?

@Abadii : Merci mais je ne peux pas utiliser de chemins absolus car je travaille sur le projet sur plusieurs machines et je ne peux pas garantir une structure de dossiers identique sur chacun d'eux. Pour moi, cela semble être un bogue - je dis à tsconfig d'exclure à la fois le dossier et les fichiers de déclaration, mais ce n'est pas le cas. Faut-il rouvrir celui-ci ?

Je vois, peut-être que la dernière chose que vous pouvez essayer est de mettre votre fichier tsconfig dans project/tsconfig.json et de changer les chemins. Je suis également à court d'options si cela ne fonctionne pas, je suppose.

A essayé:

1. Paramètre outDir -> non.
2. Paramètre allowJs: false -> non.
3. Hors .d.ts -> non.
4. noEmit: true -> non.

J'ai essayé toutes les suggestions de ce fil. Non seulement l'erreur VSCode persiste, mais elle fait référence à un fichier qui n'existe plus. ️

A essayé:

1. Paramètre outDir -> non.
2. Paramètre allowJs: false -> non.
3. Hors .d.ts -> non.
4. noEmit: true -> non.

J'ai essayé toutes les suggestions de ce fil. Non seulement l'erreur VSCode persiste, mais elle fait référence à un fichier qui n'existe plus.

Que se passe-t-il lorsque vous essayez de construire directement via le terminal ?

Définissez un outDir et assurez-vous de le rendre vide avant de construire

@Abadii Donc.... il semble que la raison pour laquelle cela se produisait était que, même si les fichiers JS n'étaient pas inclus, ils échouaient car il s'agissait de modules CommonJS.... 🤔 ....

En d'autres termes, une fois que tout avait des importations / exportations appropriées, j'ai cessé d'avoir ce problème. Donc, sur la base des commentaires de ce fil et du grand nombre de correctifs, je pense que c'est l'une de ces erreurs de hareng rouge. Comme dans, lorsqu'il y a X type de problème JS / Intellisense / compilation, alors VSCode renvoie cette erreur Cannot write file . Mais, dans mon cas, cela a été résolu avec une solution AUTRE que toutes les autres des nombreuses solutions proposées dans ce fil. 🤷‍♂️ Et encore, il a renvoyé cette erreur sur un fichier qui _n'existait pas_ et _ne serait pas remplacé_. Alors peut-être que des erreurs sont mises en cache et qu'une erreur inconnue génère une erreur mise en cache ? Quelque chose comme ca? Je pense que quelqu'un doit inspecter le code autour de cette erreur particulière.

Commenter ici parce que c'est la première chose qui est apparue dans ma recherche google.

Je suis également tombé sur ce problème. Il semble qu'une partie du processus de compilation ne reconnaisse pas qu'il se trouve dans un répertoire exclu.

Je ne vois pas le problème si je fais ça :

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

Je vois le problème si je fais ceci:

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

ou ca:

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

L'erreur se produit malgré le fait que les fichiers dont elle se plaint sont clairement à l'intérieur 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.

Dans mon cas, j'ai mis en place des importations où src/index.ts importe et réexporte à partir de src/matchers/index.ts qui à son tour importe et réexporte à partir de src/matchers/eitherMatchers/index.ts .

Les deux premiers fichiers sont ceux qui provoquent les erreurs de compilation. Le troisième fichier est bon. Il semble donc que cela puisse être lié à la manière dont l'arborescence d'importation / exportation affecte la compilation.

Je viens de tomber sur ce problème tout en ayant le même problème, et j'ai pensé ajouter ce que le mien s'est avéré être au cas où d'autres personnes le rencontreraient de la même manière.

Dans mon cas, j'ai un monorepo avec un fichier tsconfig séparé pour chaque package, qui s'étendent tous à partir d'un tsconfig de base. Chaque configuration de packages a des entrées references qui pointent vers le chemin des packages dont elle dépend. J'ai également un tsconfig.json à la racine du référentiel qui inclut files: [] et fait référence à tous les répertoires de packages. De cette façon, je peux exécuter tsc -b --watch partir de la racine et le reconstruire sur les modifications apportées tout au long du projet.

Cela a bien fonctionné pendant un certain temps, puis a soudainement commencé à générer cette erreur même si aucune des configurations n'avait changé.

Je l'ai finalement retrouvé en essayant de construire le seul package qui était signalé dans l'erreur, plutôt que de construire l'ensemble du projet.

Il s'avère que le problème était que j'avais essayé de faire importer le projet lui-même. Le nom du package était @my-project/utils , et cela fonctionnait bien jusqu'à ce que je déplace du code d'un autre package dans un fichier du package utils. Ce code comprenait import stuff from '@my-project/utils'; et c'est ce qui a causé l'erreur. En passant à import stuff from '.'; place, l'erreur a disparu.

@jasonk Cela ne fait probablement que révéler mon ignorance, mais cela ne fonctionnerait-il pas uniquement si votre monorepo est regroupé par quelque chose qui résoudra toutes ces importations (par exemple, webpack) ? Si votre monorepo est composé de modules qui peuvent être publiés et utilisés indépendamment, passer aux importations relatives provoquerait des erreurs non ?

@Ghirigoro Non, le problème n'était pas que j'utilisais un chemin de package, c'est qu'il utilisait un chemin de package pour importer un package à partir de lui-même. Même sans Typescript, cela ne fonctionnera pas.

En gros ce que j'avais fait était l'équivalent de ceci:

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

Si vous essayez ensuite de l'exécuter avec node :

$ 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 vous remplacez le nom du package, cela fonctionne correctement :

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

Je soupçonne que ce qui s'est passé, c'est que lorsque la construction a été exécutée, tous les autres packages qui importaient de @my-project/utils avaient cette importation résolue en packages/utils (car ils avaient les entrées correctes dans le references tableau node_modules/@my-project/utils , qui était un lien symbolique vers packages/utils , mais TypeScript n'a pas détecté qu'il s'agissait en fait du même projet, donc il a essayé de le construire deux fois, mais comme les deux versions avaient le même répertoire de sortie, je me suis retrouvé avec cette erreur.

Cela se produit lorsque les fichiers de déclaration ne sont pas exclus de la génération. Chaque fois que cela se produit, le générateur essaie de créer les fichiers ".d.ts" existants et de les remplacer par le même nom de fichier. C'est pourquoi vous obtiendrez l'erreur : Cannot write file ... because it would overwrite input file.

Pour éviter cela, vous pouvez exclure votre "outDir":"build" dans le fichier jour tsconfig.json :

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

ou si vous n'avez pas défini outDir, excluez tous les d.ts . fichiers d'extension :

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

J'espère que cela t'aides

L'exclusion de mon répertoire de construction a résolu le problème pour moi

Très probablement, cela se produit lorsque vous essayez d'exécuter un projet avec deux nœuds.
Pour cette hypothèse, vous pouvez tester le nombre de processus sur votre ordinateur nommé "nœud" après l'exécution de la compilation.
Ce que j'ai fait pour résoudre le problème :
Étape 1.
Comparer
node -v
et
nvm -ls , la version utilisée.
Dans le terminal, définissez la version actuelle du nœud :
nvm use {neededVersion}
En principe, supprimez les versions inutiles du nœud dans nvm (cela aidera votre IDE à déterminer automatiquement la version normale du nœud).
Étape 2.
Déterminez le nœud actuel dans votre IDE. c'est-à-dire dans WebStorm :
Préférences->Langues et frameworks -> Node.js et NPM : Interpréteur de nœud - définissez la version requise.
(De plus, vous pouvez vérifier la version du nœud pour chaque élément partout (Typescript))

En outre, ce problème peut se produire si les packages npm ou les sous-modules git utilisaient leur propre nœud à l'intérieur

J'étais confronté à ce problème pour le projet Webdriver IO / WDIO. Cela a été résolu lorsque j'ai supprimé le "wdio.config.js" de "include" dans tsconfig.json.