Typescript: Fehler "Datei kann nicht geschrieben werden ... weil sie die Eingabedatei überschreiben würde."

Ich habe auch das gleiche Problem.

ist --allowjs eingestellt? kannst du das projekt teilen?

Tut mir leid, ich kann das Projekt nicht teilen und nein, dieses Flag ist nicht gesetzt. Mein tsconfig.json ist oben, und wir verwenden es nur mit VS2015 Update 3, das den Build nur normal mit MSBuild auslöst.

Ich habe Teamkollegen, die sich über dasselbe Problem bei denselben Projekten beschweren. Ich arbeite auch zu Hause an einem Projekt auf einem anderen Computer, der genau das gleiche Problem und das gleiche Setup hat (TS 2.2.1, VS2015 U3 usw.)

Sehen Sie das gleiche Verhalten, wenn Sie ein Bare-Bones-Projekt mit den gleichen Konfigurationen erstellen?

Wir haben das gleiche Problem https://github.com/wc-catalogue/blaze-elements/issues/299 obwohl mit Typdefinitionen Schreibzugriff

@Hotell sehen Sie das ohne "awesome-typescript-loader"? Können Sie mir Repro-Schritte mitteilen?

Ja, wie Sie in der Ausgabe sehen können, ist die Ausgabe das zweite Mal, wenn raw tsc wird.

Klonen Sie einfach das Repo https://github.com/wc-catalogue/blaze-elements

• Hit yarn von root
• Hit yarn tsc -> zum ersten Mal Kompilieren (alles ist in Ordnung) => zum ersten Mal definitions/ Ordner generiert
• drücke erneut yarn tsc -> Fehler

Wir haben ein ähnliches Problem – gleiche Version von Typescript (2.2.1) und Visual Studio 2015 (Update 3); Wenn der Build zum ersten Mal ausgeführt wird, gibt es keine Fehler, aber danach erhalten wir Hunderte dieser Fehler.

Es scheint, dass sich alle Fehler (für uns) im Ordner "node_modules" befinden, den wir in unserer Datei tsconfig.json so eingestellt haben, dass er ausgeschlossen wird. -- Wenn man sich ähnliche Fehler ansieht, scheint es, als würden die Excludes in dieser Version des Typoskripts nicht gleich behandelt?

Unsere Datei 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
}

Einige der Fehler, die wir erhalten (sie sind alle gleich, aber unterschiedliche Dateien):

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

Auch hier: Wenn wir den Ordner "node_modules" löschen, funktioniert der Build einmal, aber sobald er neu erstellt wurde, schlägt er beim nächsten Neuaufbau fehl.

@Hotell Ich

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 Wenn Sie ein Repro-Projekt haben, würde ich gerne einen Blick darauf werfen.

Ich stehe auch vor dem gleichen Problem, das sind die Fehler:

Und das ist meine tsconfig.json:

Da ich überhaupt kein Typoskript verwende, habe ich gerade tsconfig erstellt, um den Build zu überspringen, ich musste auch target=ES6 wählen, sonst hatte ich andere Fehler.

ist die tsconfig.json Teil Ihres Projekts? und können Sie bestätigen, dass der Inhaltstyp "Inhalt" ist? Wenn ja, können Sie Ihr Projekt teilen?

@mhegazy Hallo, ja, ich kann bestätigen, dass tsconfig.json im Projekt enthalten ist:

Aber es tut mir leid, ich weiß nicht, auf welchen "Inhaltstyp" Sie sich beziehen. Können Sie das bitte klären?

Ich kann das Projekt nicht teilen.

In meinem Projekt kann ich auch bestätigen, dass die Datei tsconfig in der Projektdatei enthalten ist und als Inhalt aufgeführt ist.

@max-favilli Ich denke, @mhegazy bedeutet die "Build-Aktion", wenn es um "Inhaltstyp" geht.

Wählen Sie im Lösungs-Explorer tsconfig.json aus. Rufen Sie das Eigenschaftenfenster auf (standardmäßig F4-Taste). Es wird eine Build Action-Eigenschaft geben.

Danke @kevindqc , @mhegazy ja "Build Action" ist auf "content" gesetzt

Können Sie Ihre virtuelle Projektstruktur mit mir teilen, um das zu erhalten, müssen Sie:

• gehe zu Tools > Options > Text Editor > TypeScript > Project und kreuze Display Virtual Projects when no Solution is loaded ;
• Starten Sie VS neu und öffnen Sie eine Datei in Ihrem Projekt
• Sie sollten jetzt in Ihrem Projektmappen-Explorer einen neuen Knoten mit dem Namen TypeScript Virtual Project

@mhegazy gefällt das?

Danke fürs Helfen.

Ich habe das gleiche Problem. Ich kann das Projekt auch nicht teilen, aber ich werde versuchen, so viele Informationen wie möglich bereitzustellen.

Ich habe die Typoskript-Kompilierung in der .csproj-Datei deaktiviert ( <TypeScriptCompileBlocked>true</TypeScriptCompileBlocked> )
Stattdessen wird es von npm run build:prod kompiliert, das sich in einem Build-Ereignis befindet.

Die Fehler sind nicht immer da. Ich habe versucht, sie erscheinen zu lassen (sie wurden in VS angezeigt, also habe ich VS neu gestartet). Ich habe versucht, das Typoskript-Projekt zu erstellen, die Lösung zu erstellen, Tests auszuführen, Codeanalysen auszuführen, Codeabdeckung auszuführen usw. Nichts löst es aus. Dann, gerade als ich den letzten Satz schrieb, tauchten die Fehler auf. Es scheint also einige Hintergrundaufgaben zu sein, die es tun? Es scheint ungefähr 2 Minuten zu passieren, nachdem ich einen Build gestartet habe (zumindest die 2-3 Mal, die ich es ausprobiert habe)

Zeitleiste:
1:37:20 - Visual Studio geöffnet
1:37:30 - Lösungserstellung gestartet
1:38:20 - Bau fertig
1:39:39 - Es sind Fehler aufgetreten

Mir ist aufgefallen, dass mein Projekt immer noch die v2.0.3 Microsoft.TypeScript.Compiler und Microsoft.TypeScript.MSBuild Nuget-Pakete verwendet. Ich habe sie auf v2.2.1 aktualisiert. Bisher kein Fehler. Werde aktualisieren, wenn ich die Fehler wieder sehe. (Bearbeiten: Ich sehe die Fehler wieder, obwohl es etwas länger gedauert hat, ~ 5 Minuten, ohne dass ich beim Öffnen von VS etwas anderes getan habe als zu bauen. Eigentlich muss ich nicht einmal etwas bauen, um den Fehler zu erhalten - nur das Öffnen der Projekt und warten ein paar Minuten zeigt die Fehler)

Ist das bei diesen veralteten Nuget-Paketen normal? Ich glaube, ich habe ein Popup zum Aktualisieren meiner Projekt-Typoskript-Tools erhalten, als ich die neue Version von Typoskript installiert habe, aber es scheint, dass es nur <TypeScriptToolsVersion>2.2</TypeScriptToolsVersion> aktualisiert hat. Sollte es nicht auch die Nuget-Pakete aktualisieren?

Ich habe gerade auf Typescript 2.2.1 aktualisiert und habe das gleiche Problem. Es markiert alle node_modules, aber der tsc-Compiler wird ohne Probleme abgeschlossen.

@mhegazy

@Hotell Ich

richtig, es wurde behoben von https://github.com/wc-catalogue/blaze-elements/commit/cdb94bf8feb3a1ad7e21e6fce243e3322c1334cc

sry für verspätete antwort und thx 4 hilfe!

@Hotell @mhegazy Scheint bei mir nicht zu funktionieren.
Vielleicht funktioniert es, wenn Sie d.ts-Dateien in einem Ordner "definitions" haben?
Aber das habe ich nicht. Ich habe @types unter "node_modules", die vererbt ausgeschlossen werden sollen?

@chrismbarr Darf ich fragen, ob du das schon gelöst hast? Ich habe den Thread verfolgt und sogar die von @Hotell vorgeschlagene erhalte immer noch diese Fehler in Visual Studios. Sie scheinen alle aus dem Ordner node_modules zu kommen.

Könnten Sie eine detaillierte Protokollierung aktivieren und uns die Ergebnisse senden? Setzen Sie die Systemumgebungsvariable TSS_LOG auf einen Wert wie -file C:/temp/logs/tsserver.log -level verbose (stellen Sie sicher, dass der Ordner logs vorhanden ist). Nachdem Sie das Problem reproduziert haben, senden/hängen Sie das Protokoll zur Analyse an. (Hinweis: Es kann Daten wie Dateipfade und Vervollständigungslisten enthalten, stellen Sie also sicher, dass keine Daten enthalten sind, die Sie nicht teilen möchten).

Bei meinen Tests habe ich gelegentlich gesehen, wie das Projektsystem eine Ansicht des Projekts erstellt, die die falschen Dateien enthält, was zu unvorhersehbaren zeitweiligen Fehlern führt. Ich würde gerne sehen, ob das hier die Ursache sein kann.

Ich kann meine E-Mail-Adresse angeben, wenn Sie die Dateien lieber direkt senden möchten, als sie hochzuladen (billti bei microsoft dot com). Vielen Dank.

@johnlee nein, immer noch das gleiche in VS2015. Ich habe jedoch seitdem begonnen, Visual Studio 2017 zu verwenden, und ich habe keine Fehler darin!

@billti Variable hinzugefügt, Visual Studio (2017) neu gestartet, Lösung neu erstellt, aber die Protokolldatei wird nicht erstellt. Was sollte ich überprüfen?

Ist es definitiv eine Systemumgebungsvariable (dh wenn Sie eine neue Eingabeaufforderung öffnen und SET TSS ausführen, ist die Einstellung aufgeführt)? Wenn nicht, ist der Ordner, in den das Log geschrieben werden soll, bereits vorhanden (der Logger erstellt keine Verzeichnisse, die nicht existieren). Abgesehen davon ist es auch sicherer, Schrägstriche anstelle von umgekehrten Schrägstrichen im Pfad zu verwenden.

:(

@billti Ok, ich habe gerade nachgesehen und die Protokolldateien sind jetzt da. Bitte finden Sie sie hier angehängt
tss-log.zip

Vielen Dank. Ich habe in diesem Protokoll nachgesehen, und ich sehe nicht, dass dieser Fehler von Anrufen darin gemeldet wird. Ist der Fehler definitiv in dem Zeitraum aufgetreten, den dieses Protokoll abdeckt?

@billti Ja, die Fehler treten ständig auf:

Sie sind einfach dauerhaft da. Und bei jedem einzelnen Build aufgefrischt.

All diese Fehler bezogen sich auf falsche Variablendeklarationen (ein separates Problem, das wir bereits für eine kommende Version behoben haben). Dieses Problem ist ungefähr Cannot write file... pro Titel und Screenshots oben. Haben Sie das Problem mit Cannot write file... nicht?

@billti Nachdem ich meine vorherige Nachricht
Ich habe diese Fehler aus der vorherigen Nachricht beseitigt, indem ich nur die Typen aus @types entfernt habe.
Danke vielmals.

@billti Ich versuche, Ihnen einige Protokolle zu senden, aber keine werden erstellt. Ich habe TSS_LOG -file C:/temp/logs/tsserver.log -level verbose in meinen Systemvariablen (nicht Benutzervariablen) auf

C:\temp\logs existiert und ich habe Everyone die volle Kontrolle gegeben.

Wenn ich mein VS2015 neu starte, wird in C:\temp\logs nichts erstellt, auch wenn ich alle meine Cannot write file... Fehler erhalte. Wenn ich versuche, node node_modules\typescript\lib\tsserver.js (und sofort STRG+C) in eine neue Eingabeaufforderung einzugeben, erhalte ich zwei Protokolldateien.

Entschuldigung @kevindqc , ich wusste nicht, dass Sie auf VS 2015 waren. Diese Protokollierung gilt nur für VS 2017 (das jetzt tsserver.js außerhalb des Prozesses für den Sprachdienst verwendet).

Gehen Sie zurück und betrachten Sie Ihr Problem - wenn sich die Fehlerliste zufällig ändert, glaube ich, dass dies das gleiche Problem ist, das @zhengbli gerade in https://github.com/Microsoft/TypeScript/pull/15080 behoben hat.

@billti np. Ich denke, dieses Problem tritt nur auf VS2015 auf, nicht wahr? Der einzige Benutzer mit dem Problem, der VS2017 verwendet hat, hatte verschiedene Fehler im Zusammenhang mit der Eingabe. Jemand, der von VS2015 auf VS2017 umgestiegen ist, sagte, das Problem sei verschwunden.

Außerdem ändert sich die Fehlerliste nicht zufällig - sie wird zu einem zufälligen Zeitpunkt einmal mit all den "Cannot write .."-Fehlern gefüllt, um die es bei diesem Problem geht. Sind Sie sicher, dass #15080 es behebt? Ich sehe zu diesem Problem nichts außer dem Hinweis, den Sie gestern darauf gemacht haben? Wie kann ich es testen? Ich sehe, es gibt ein 2.3 RC, aber es wurde vor 9 Tagen veröffentlicht, während der Fix vor 2 Tagen zusammengeführt wurde :(

Außerdem ist mir aufgefallen, dass die Fehler auch nach dem Schließen der Lösung in meiner Fehlerliste bleiben.

Auch die Person, die sein virtuelles Typoskript-Projekt veröffentlichte, war diejenige mit den verschiedenen Fehlern, daher stelle ich mir vor, dass es nicht hilfreich war. Hier ist mein:

Soll node_modules dort sein? Es ist in meiner tsconfig ausgeschlossen. Es enthält jedoch nicht alles, was mein physischer node_modules-Ordner hat (14 Unterordner vs 854 Unterordner in meinem node_modules-Ordner)

{
  "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
  }
}

Hatte die Fehler nach dem Upgrade auf die TS2.3-Tools bisher nicht. Vielen Dank!
Edit: Nö. Die Fehler sind immer noch da, es hat nur länger gedauert, bis sie auftauchten.

Scheint, dass dieses Problem mit diesem Problem zusammenhängt . Beispiellösung zum Reproduzieren - hochgeladen.

Ich habe eine Lösung für mich gefunden. In meinem Fall habe ich outDir und rootDir ohne das Array files anzugeben. Beim Hinzufügen des Pfads von outDir zum Array exclude scheint alles normal zu funktionieren.

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

Vielleicht überwacht TypeScript auch den Inhalt des Ordners dist , obwohl er als outDir .

Wenn Sie Ihre outDir unter Ihrem Projektstamm haben und nur alles unter dem Stamm einschließen, wird dies erwartet. Im Allgemeinen möchten Sie Ihre Build-Ausgabe an einem anderen Ort als im Quellordner des Projekts haben.

Anscheinend werden alle oben genannten Probleme in diesem Thread oder verlinkten Problemen behandelt. Lassen Sie es mich wissen, wenn dies nicht der Fall ist, und ich werde wieder öffnen. Vielen Dank!

@billti Ich rootDir der Compiler nur diesen bestimmten Ordner überwacht und alles andere ausschließt. Aber das aktuelle Verhalten macht Sinn.

beste lösung ist von borislemke .
{ "compilerOptions": { ..., "outDir": "./dist", "rootDir": "./src", }, "exclude": [ "node_modules", "dist" <-- I had to add this to fix the errors ] }

Ich bin auf das gleiche Problem gestoßen und habe festgestellt, dass einer meiner Importe fälschlicherweise auf die Klasse in meinem Dist-Ordner EG verweist
importiere {ClassName} aus "../../dist/ClassName";

Da sich die importierende Klasse im selben Ordner befand, habe ich sie geändert in:
importiere {ClassName} aus "./ClassName";

und alles wird wieder kompiliert :)

Wir hatten einen vordefinierten 'dist'-Ordner in unserer App. Das Löschen hat es bei mir behoben.

Ich denke, dies ist das zugrunde liegende Problem (das letzte Windows Creators Update):
visual-studio-2015-löscht-file-on-save-cordova-solution

Fügen Sie einfach Ihren Ordner "dist" zur Ausschlussliste in tsconfig.json hinzu
Ex:
"exclude": ["node_modules", "dist"]

Ich habe dies korrigiert, indem ich einen Abschnitt zum Einschließen hinzugefügt habe:

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

Ich bin auch darauf gestoßen, als ich ein outDir das sich in meinem Quellenverzeichnis befand.

Wie kommt es, dass der Typoskript-Compiler standardmäßig nicht weiß, dass er nicht versuchen sollte, Dinge in outDir zu kompilieren? Das scheint seltsam. Das Hinzufügen des Outdirs zur Ausschlussliste hat es jedoch behoben.

Ich habe dieses Problem mit Netbeans lol

Ich habe diesen Fehler auch bekommen, als ich zwei Dateien hatte foo.ts und foo.tsx , die beide natürlich zu foo.js kompilieren würden.

  "compilerOptions": {
    "noEmit": true 
  }

Habe es für mich behoben.

noEmit ist eine bessere Lösung, wenn Sie generierte *.js Dateien zur Analyse haben möchten. Sie werden ja nicht unbedingt mit tsc generiert.

In meinem Fall generiert Ream.js .ream/**.js die ich dann mit import XXX from '#out/yyy' in meinen Code importiere (was funktioniert, aber die Warnung "Datei kann nicht geschrieben werden ..." in VS Code generiert wird).

Grundsätzlich ist der einzige Grund, "noEmit": false wenn Sie rohes tsc . Für alle anderen Umgebungen ( ts-node / ts-node-dev , Webpack, Rollup) ist es sicherer, es zu aktivieren.

Wie @uglycoyote funktionierte für mich das Hinzufügen von outdir zum Excludes-Array. Keiner der anderen Vorschläge hat funktioniert.

Ich habe das Gefühl, dass dieses Problem mit diesen zusammenhängt:

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

Das Problem tritt bei mir auf, weil ich "declaration": true in tsconfig.json , sodass es sich über die d.ts Dateien im Build-Ordner ärgert, obwohl das Verzeichnis außerhalb des Verzeichnisses liegt Wurzel. Ich kann einen neuen Build ohne Probleme erstellen, aber jeder Build danach wirft: Cannot write file ... because it would overwrite input file. . Nach dem, was ich in den anderen Geschichten sehen konnte, hat das in einer anderen Version funktioniert, dann muss sich etwas geändert haben.

So wie ich die Probleme behoben habe, dass meine test.ts Dateien außerhalb der rootDir ich Folgendes zu den tsconfig.json hinzufügen.

"exclude:" [ "./build" ]

Dies kann auch bei der Konfigurationsvererbung passieren. Jede Konfiguration muss outDir separat angeben. Es scheint, dass der Pfad in outDir absolut aufgelöst ist. Könnte aus Sicht des Benutzers sogar ein Fehler sein.

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

Es lohnt sich auch zu überprüfen, ob Sie innerhalb von package.json einen fehlerhaften Verweis auf das "outDir" haben

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

Dies habe ich in einem Projekt mit Projektreferenzen erlebt. Keiner der Ausschlüsse spielte eine Rolle, was tat, war der von @elmpp angedeutete Eintrag typings .

Dies erzeugt also TS5055: Cannot write file because it would overwrite input file in einem Projekt, das auf Monorepo verweist:

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

aber dies wird keine Fehler melden:

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

Offensichtlich muss ich diese Vorveröffentlichung entweder manipulieren oder die src im Paket veröffentlichen.

Einstellung:

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

hat es für mich behoben (mein outputDir war dist ).

Es könnte großartig sein, wenn das Ausgabeverzeichnis standardmäßig für tsc --watch .

Zur späteren Bezugnahme geschieht dies, wenn Sie ein Modul aus sich selbst importieren.

Wenn Sie also import x from 'mymodule tun, wenn Sie sich innerhalb von mymodule wird dies ausgelöst. Es ist sehr kryptisch und sollte wahrscheinlich behoben werden!

Similary, schlug ich das Problem , wenn Sie eine haben index.ts mit einem Bündel von Linien wie export * from './foo' , und in einer dieser Dateien, war ich den Import mit import foo from '.' statt import foo from './foo' in einer dieser exportierten Dateien.

Ich habe mir die letzten zwei Tage den Kopf darüber zerbrochen, bis ich index.ts gelöscht habe und einen Importfehler hatte. Es war sehr nicht offensichtlich.

Ich denke also, das Problem lag daran, dass ich 2 ts-Projekte im selben Repo habe. (Angular & Nestjs), die tsconfig.json des Ordners der Ebene 1 löst diesen Fehler aus. Ich habe das behoben, indem ich "public" ausschließen, was in der Öffentlichkeit mein Angular-Code mit seiner eigenen tsconfig.json ist.

Ich hatte dieses Problem, weil ich nicht sicher war, warum ts-node nicht funktionierte, dann tsc , um zu überprüfen, ob das Problem TypeScript war. Als Ergebnis von tsc hatte ich jetzt Dutzende von .js Dateien Seite an Seite mit den ts die ich durch Ausführen von git status

Die Lösung war git clean -f .

In meinem Fall scheint es, dass VS Code automatisch eine Datei aus dem Ordner dist anstatt aus dem Ordner src importiert hat. Das zu beheben löste das Problem.

Dies sollte wirklich nicht geschlossen werden, Typskript sollte einen Fehler ausgeben, der Ihnen sagt, was los ist. Es ist derzeit fast unmöglich, das herauszufinden. Ich bin mir nicht sicher, was dies von Zeit zu Zeit verursacht, VSCode aktualisiert möglicherweise versehentlich tsconfig.json-Referenzen, aber es verlangsamt alles um eine Menge und jedes Mal war das Debuggen nicht trivial.

Im Vue-Projekt hat das im Stammverzeichnis für mich funktioniert:

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

Nachdem ich das hinzugefügt habe
"outDir": "",
Problem war weg.

Mein Ziel hier ist nur, ts-Intelligenz in .js/vue-Dateien zum Laufen zu bringen.

Hatte die gleiche Fehlermeldung. Problem war , dass ich hatte zwei Dateien mit dem gleichen Namen , aber unterschiedlicher Erweiterung im selben Ordner so das Entfernen den einen mit .js Erweiterung festgelegt , dass.

Hatte die gleiche Fehlermeldung. Problem war , dass ich hatte zwei Dateien mit dem gleichen Namen , aber unterschiedlicher Erweiterung im selben Ordner so das Entfernen den einen mit .js Erweiterung festgelegt , dass.

Ja ich hatte das gleiche Problem. Ich hatte eine .tsx Datei in .ts , die VS-Code hilfreicherweise neu erstellt hatte, was das Problem verursachte.

Ich bin mir nicht sicher, wie man das richtig löst, aber in meinem Fall habe ich gerade "declaration": true aus tsconfig.json entfernt. D.ts-Dateien werden nicht erzeugt, aber ich brauche sie sowieso nicht.

An alle, die hierher gekommen sind, indem sie eine ähnliche Fehlermeldung gegoogelt haben, lassen Sie mich meine Ergebnisse teilen:

1. Wie Sie lesen können, wurde dieser Fehler verursacht, weil der TypeScript-Compiler versuchte, eine .js-Datei in denselben Pfad zu kompilieren.
2. Höchstwahrscheinlich möchten Sie überhaupt keine .js-Dateien kompilieren. Entfernen Sie nach Möglichkeit allowJs: true aus Ihrer tsconfig.json oder --allow-js aus Ihren CLI-Optionen.
3. Falls Sie diese unbedingt benötigen, möchten Sie vielleicht die Dateien, die in der Fehlermeldung genannt wurden, von der Kompilierung ausschließen. Einige Leute in diesem Thread haben das (vielleicht ohne es zu merken) getan, indem sie exclude: ... hinzugefügt haben.
   
   
   
   • Achten Sie darauf, nicht 'exclude' unter compilerOptions hinzuzufügen.
   
   

Hoffe es hilft 🙏

Ich musste mein Build-Verzeichnis lib/ manuell ausschließen

Irgendwo scheint ein Fehler zu sein, der einige Optionen inkompatibel macht. Ich habe herausgefunden, dass mit
allowJS true +
rootDir + outDir : OK
rootDir + outFile : NOK : rootDir nicht berücksichtigt : alle Dateien in dir und Unterverzeichnis werden kompiliert und möglicherweise überschrieben.
einige andere Optionskombinationen sind verboten.

"allowJs": true
"noEmit": true
arbeite für mich.

Im Vue-Projekt hat das im Stammverzeichnis für mich funktioniert:

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

Nachdem ich das hinzugefügt habe
"outDir": "",
Problem war weg.

Mein Ziel hier ist nur, ts-Intelligenz in .js/vue-Dateien zum Laufen zu bringen.

thx, bei mir funktioniert es.

Wenn Sie TS NUR zur .js Dateien benötigen, verwenden Sie die @guaizi149- Lösung:

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

Dies teilt TS mit, dass es sich nicht um die Kompilierung kümmern sollte, daher wird keine Datei überschrieben und keine Warnung ausgelöst. Dies ist eine bessere Lösung für die Verwendung von outDir: "" .

Dies kann auch bei der Konfigurationsvererbung passieren. Jede Konfiguration muss outDir separat angeben. Es scheint, dass der Pfad in outDir absolut aufgelöst ist. Könnte aus Sicht des Benutzers sogar ein Fehler sein.

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

Diese Lösung hat für mich wie ein Zauber funktioniert! Mein tsconfig.json sieht jetzt so aus:

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

"allowJs": true
"noEmit": true
arbeite für mich.

Danke @guaizi149 , deine Lösung funktioniert bei mir 👍

Gelöst - hatte das Verzeichnis dist in meinen tsc-Build aufgenommen:

"exclude": [
    "node_modules"
  ]

--- geht zu

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

Ist dist Ihr Build-Ordner?

Wenn das Ausschließen von outDir für Sie nicht funktioniert hat, versuchen Sie zu überprüfen, ob Sie doppelte Dateien mit demselben Pfad und Dateinamen, aber unterschiedlichen Erweiterungen haben.

Dies geschieht, wenn die Deklarationsdateien nicht vom Build ausgeschlossen werden. Wenn dies auftritt, versucht der Builder, die vorhandenen ".d.ts"-Dateien zu erstellen und sie durch denselben Dateinamen zu ersetzen. Deshalb erhalten Sie die Fehlermeldung: Cannot write file ... because it would overwrite input file.

Um dies zu verhindern, können Sie Ihre "outDir":"build" in der Datei jour tsconfig.json ausschließen:

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

oder wenn Sie outDir nicht definiert haben, schließen Sie alle d.ts . Erweiterungsdateien:

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

Hoffe das hilft

@Abadii : Vielleicht liegt es daran, dass ich beim Kompilieren die Option -b verwende, aber keiner dieser Ansätze hat funktioniert.

@Abadii : Vielleicht liegt es daran, dass ich beim Kompilieren die Option -b verwende, aber keiner dieser Ansätze hat funktioniert.

Können Sie Ihre tsconfig.json Datei teilen und welche Version hat Ihr tsc ?

@Abadii : Hier ist es (natürlich ohne den aktualisierten Ausschluss). Die Version von tsc ist 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 : Hier ist es (natürlich ohne den aktualisierten Ausschluss). Die Version von tsc ist 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"]
}

Bitte schauen Sie sich das folgende Repo an. Ich habe Ihre tsconfig.json verwendet, um den Fehler zu regenerieren:

https://github.com/Abadii/tsconfig

PS Und was passiert, wenn Sie Ihren ../lib-Ordner löschen? Wird es bauen?

@Abadii : Es wird erstellt, wenn ich den Build-Ordner entferne (eigentlich wird es nur erstellt , wenn ich den Build-Ordner entferne/leere). Dies gilt auch, wenn ich exclude Deklarationsdateien und den Build-Ordner habe.
Zur Info die Projektstruktur ist wie folgt:

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

und ich baue mit: tsc -p ./src/tsconfig.json
(eigentlich baue ich normalerweise mit rm -rf ./lib && tsc -p src/tsconfig.json aber das ist es, was ich hier beheben möchte ;) )

@Abadii : Es wird erstellt, wenn ich den Build-Ordner entferne (eigentlich wird es nur erstellt , wenn ich den Build-Ordner entferne/leere). Dies gilt auch, wenn ich exclude Deklarationsdateien und den Build-Ordner habe.

Jetzt wissen Sie also, dass der Build-Ordner das Problem verursacht. Irgendwie schließt Ihr tsc Build Ihren Build-Ordner nicht aus. Sie können versuchen, den absoluten Pfad im Ausschluss zu verwenden.
Ich habe auch festgestellt, dass Ihr Build-Ordner außerhalb Ihres Bereichs liegt ../lib . Vielleicht ist das auch der Grund, warum es nicht ausschließt. Versuchen Sie ./lib als outDir, um zu überprüfen, ob es das Verhalten ändert
Wenn Sie ein Windows-Benutzer sind, überprüfen Sie, ob der definierte absolute Pfad korrekt ist.

@Abadii : Danke, aber ich kann keine absoluten Pfade verwenden, da ich auf mehreren Computern an dem Projekt arbeite und nicht auf allen eine identische Ordnerstruktur garantieren kann. Für mich scheint dies ein Fehler zu sein - ich sage tsconfig, sowohl die Ordner- als auch die Deklarationsdateien auszuschließen, aber das ist nicht der Fall. Soll das wieder geöffnet werden?

@Abadii : Danke, aber ich kann keine absoluten Pfade verwenden, da ich auf mehreren Computern an dem Projekt arbeite und nicht auf allen eine identische Ordnerstruktur garantieren kann. Für mich scheint dies ein Fehler zu sein - ich sage tsconfig, sowohl die Ordner- als auch die Deklarationsdateien auszuschließen, aber das ist nicht der Fall. Soll das wieder geöffnet werden?

Ich verstehe, vielleicht ist das Letzte, was Sie versuchen können, Ihre tsconfig-Datei in project/tsconfig.json abzulegen und die Pfade zu ändern. Ich habe auch keine Optionen, wenn das nicht funktioniert, denke ich.

Versucht:

1. Einstellung von outDir -> nein.
2. Einstellung von allowJs: false -> nein.
3. Ausgenommen .d.ts -> nein.
4. noEmit: true -> nein.

Ich habe jeden Vorschlag in diesem Thread ausprobiert. Der VSCode-Fehler bleibt nicht nur bestehen, sondern bezieht sich auch auf eine Datei, die nicht mehr existiert. ️

Versucht:

1. Einstellung von outDir -> nein.
2. Einstellung von allowJs: false -> nein.
3. Ausgenommen .d.ts -> nein.
4. noEmit: true -> nein.

Ich habe jeden Vorschlag in diesem Thread ausprobiert. Der VSCode-Fehler bleibt nicht nur bestehen, sondern bezieht sich auch auf eine Datei, die nicht mehr existiert.

Was passiert, wenn Sie versuchen, direkt über das Terminal zu bauen?

Legen Sie ein outDir fest und stellen Sie sicher, dass es leer ist, bevor Sie es bauen

@Abadii Also .... anscheinend war der Grund dafür, dass die JS-Dateien, obwohl sie nicht enthalten waren, fehlschlugen, weil es sich um CommonJS-Module handelte .... 🤔 ....

Mit anderen Worten, sobald alles ordnungsgemäße Importe / Exporte hatte, bekam ich dieses Problem nicht mehr. Aufgrund der Kommentare in diesem Thread und der schieren Anzahl der Korrekturen denke ich, dass dies einer dieser Ablenkungsfehler ist. Wenn ein JS- / Intellisense- / Kompilierungsproblem vom Typ X auftritt, löst VSCode diesen Cannot write file Fehler aus. Aber in meinem Fall wurde dies mit einer anderen Lösung als jeder anderen der zahlreichen in diesem Thread angebotenen Lösungen gelöst. 🤷‍♂️ Und wieder wurde dieser Fehler auf eine Datei geworfen, die _nicht existierte_ und _nicht ersetzt werden würde_. Vielleicht werden Fehler zwischengespeichert und ein unbekannter Fehler löst einen zwischengespeicherten Fehler aus? Sowas in der Art? Ich denke, jemand muss den Code um diesen speziellen Fehler herum überprüfen.

Kommentieren hier, weil es das erste ist, was in meiner Google-Suche auftauchte.

Ich bin auch auf dieses Problem gestoßen. Es scheint, als würde ein Teil des Kompilierungsprozesses nicht erkennen, dass er sich in einem ausgeschlossenen Verzeichnis befindet.

Ich sehe das Problem nicht, wenn ich dies tue:

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

Ich mache das Problem sehen , wenn ich dies tun:

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

oder dieses:

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

Der Fehler tritt auf, obwohl sich die beanstandeten Dateien eindeutig in 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.

In meinem Fall habe ich Importe eingerichtet, bei denen src/index.ts von src/matchers/index.ts importiert und wieder exportiert, die wiederum von src/matchers/eitherMatchers/index.ts importiert und wieder exportiert werden.

Die ersten beiden Dateien verursachen die Kompilierungsfehler. Die dritte Datei ist in Ordnung. Es sieht also so aus, als ob es damit zusammenhängt, wie sich der Import- / Exportbaum auf die Kompilierung auswirkt.

Ich bin gerade über dieses Problem gestolpert, während ich das gleiche Problem hatte, und dachte, ich würde hinzufügen, was meins war, falls andere Leute auf die gleiche Weise darüber stolpern.

In meinem Fall habe ich ein Monorepo mit einer separaten tsconfig-Datei für jedes Paket, die alle von einer Basis-tsconfig ausgehen. Jede Paketkonfiguration hat references Einträge, die auf den Pfad der Pakete verweisen, von denen sie abhängt. Ich habe auch eine tsconfig.json im Stammverzeichnis des Repositorys, die files: [] und Verweise auf alle Paketverzeichnisse enthält. Auf diese Weise kann ich tsc -b --watch vom Stamm aus ausführen und es bei Änderungen während des gesamten Projekts neu aufbauen lassen.

Dies funktionierte eine ganze Weile gut und begann dann abrupt, diesen Fehler zu werfen, obwohl sich keine der Konfigurationen geändert hatte.

Ich habe es schließlich aufgespürt, indem ich versucht habe, das eine Paket, das im Fehler gemeldet wurde, selbst zu erstellen, anstatt das gesamte Projekt zu erstellen.

Es stellte sich heraus, dass das Problem darin bestand, dass ich versucht hatte, das Projekt selbst zu importieren. Der Paketname war @my-project/utils , und es hat gut funktioniert, bis ich etwas Code aus einem anderen Paket in eine Datei im utils-Paket verschoben habe. Dieser Code enthielt import stuff from '@my-project/utils'; und das war es, was den Fehler verursachte. Durch den Wechsel zu import stuff from '.'; ging der Fehler stattdessen weg.

@jasonk Dies enthüllt wahrscheinlich nur meine Unwissenheit, aber würde das nicht nur funktionieren, wenn Ihr Monorepo durch etwas gebündelt wird, das all diese Importe auflöst (zB Webpack)? Wenn Ihr Monorepo aus Modulen besteht, die unabhängig voneinander veröffentlicht und verwendet werden können, würde die Umstellung auf relative Importe Fehler verursachen, nein?

@Ghirigoro Nein, das Problem war nicht, dass ich einen Paketpfad verwendet wurde , um ein Paket aus sich selbst zu importieren. Auch ohne Typescript geht das nicht.

Im Grunde war das, was ich getan hatte, das Äquivalent davon:

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

Wenn Sie dann versuchen, das mit Knoten auszuführen:

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

Wenn Sie den Paketnamen ersetzen, funktioniert es korrekt:

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

Ich vermute, dass beim Ausführen des Builds der Import @my-project/utils allen anderen Paketen, die aus packages/utils (weil sie die richtigen Einträge in der references Array in tsconfig), sodass sie normal gebaut wurden. Aber da dieses Paket nicht selbst importiert werden sollte, wurde dieser Import in node_modules/@my-project/utils , was ein symbolischer Link zu packages/utils , aber TypeScript hat nicht erkannt, dass es sich tatsächlich um dasselbe Projekt handelt, also Es hat zweimal versucht, es zu erstellen, aber da beide Builds das gleiche Ausgabeverzeichnis hatten, kam es zu diesem Fehler.

Dies geschieht, wenn die Deklarationsdateien nicht vom Build ausgeschlossen werden. Wenn dies auftritt, versucht der Builder, die vorhandenen ".d.ts"-Dateien zu erstellen und sie durch denselben Dateinamen zu ersetzen. Deshalb erhalten Sie die Fehlermeldung: Cannot write file ... because it would overwrite input file.

Um dies zu verhindern, können Sie Ihre "outDir":"build" in der Datei jour tsconfig.json ausschließen:

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

oder wenn Sie outDir nicht definiert haben, schließen Sie alle d.ts . Erweiterungsdateien:

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

Hoffe das hilft

Das Ausschließen meines Build-Verzeichnisses hat das Problem für mich gelöst

Dies geschieht höchstwahrscheinlich, wenn Sie versuchen, ein Projekt mit zwei Knoten auszuführen.
Für diese Hypothese können Sie die Anzahl der Prozesse auf Ihrem Computer mit dem Namen "node" nach dem Ausführen des Builds testen.
Was ich getan habe, um das Problem zu lösen:
Schritt 1.
Vergleichen
node -v
und
nvm -ls , die verwendete Version.
Im Terminal-Set aktuelle Knotenversion:
nvm use {neededVersion}
Löschen Sie im Prinzip unnötige Versionen des Knotens in nvm (dies hilft Ihrer IDE, automatisch die normale Version des Knotens zu ermitteln).
Schritt 2.
Bestimmen Sie den aktuellen Knoten in Ihrer IDE. dh in WebStorm:
Einstellungen -> Sprachen & Frameworks -> Node.js und NPM: Node Interpreter - benötigte Version einstellen.
(Zusätzlich können Sie die Version des Knotens für jedes Element überall überprüfen (Typescript))

Dieses Problem kann auch auftreten, wenn die npm-Pakete oder git-Submodule einen eigenen Knoten verwendet haben

Ich hatte dieses Problem für das Webdriver IO / WDIO-Projekt. Es wurde behoben, als ich "wdio.config.js" aus "include" in tsconfig.json entfernte.