Typescript: Unterdrückung des Fehlers "Der Importpfad kann nicht mit der Erweiterung '.ts' enden"?

Angenommen, Sie haben zwei Dateien:
a.ts : import * as b from "./b.ts";
b.ts : export const b: number = 0;

Wenn wir a.ts kompilieren, ändern wir die Importspezifizierer nicht . Die Ausgabe a.js enthält also denselben Importspezifizierer "./b.ts", obwohl er möglicherweise in require("./b.ts") .
Wenn Sie dann versuchen, a.js auszuführen, b.ts zum Importieren vorhanden sind, sondern nur b.js . (Oder ohne --outDir wobei b.js neben b.ts , wird der Import in b.ts und das Parsen bei : number fehlgeschlagen. )

Stattdessen sollten Sie die Dateierweiterung bei Ihren Importen weglassen oder die Erweiterung .js .

nein ， Ich benutze deno exec die Datei。 ohne zu kompilieren。

@ hooper-hc
Ich denke, wir können tsconfig als vorübergehende Lösung wie diese festlegen:

{
  "compilerOptions": {
    "module": "amd",
    "target": "esnext",
    "baseUrl": ".",
    "paths": {
      "http://*": ["../../../.deno/deps/http/*"],
      "https://*": ["../../../.deno/deps/https/*"],
      "*.ts": ["*"]
    }
  }
}

Ich benutze auch Deno. Ich fand, dass das Kommentieren von // @ts-ignore jeder Zeile eines Imports funktioniert.

// @ts-ignore
import coerceToArray from './journey.coerce-to-array.ts'
// @ts-ignore
import fnFree from './journey.fn-free.ts'
// @ts-ignore
import fnReduce from './journey.fn-reduce.ts'

Gibt es überhaupt eine Möglichkeit, diese Anforderung in ts-config global auszuschalten?

Ich habe auch die Lösung von @zhmushan ausprobiert und das Problem wurde dadurch nicht

@reggi entferne ./
Ich hoffe, dass wir in Zukunft eine Konfiguration ähnlich module:deno , um den Vorgang zu vereinfachen.

Wäre das TypeScript-Team offen dafür, der tsconfig "module": "deno" hinzuzufügen? Auf diese Weise können wir die Verwendung der Erweiterung .ts nativ unterstützen, ohne auf etwas wie kitsonk / deno_ls_plugin als

import module from 'module';

Es wird ein Fehler wie Cannot have an extensionless import with module:deno (die einzigen zulässigen Importe sind vollständige URLs und relative Importe, die mit ./ oder ../ ). Eine solche Konfiguration könnte auch die native Suche im Ordner $DENO_DIR/deps nach Typen unterstützen, da wir derzeit eine Pfadeinstellung verwenden müssen, um dies zu umgehen. Darüber hinaus könnten automatische Importe auch ordnungsgemäß funktionieren, da sie derzeit immer den erweiterungslosen Import ausführen (was bedeutet, dass Sie ihn ohnehin manuell bearbeiten müssen).

Dies scheint ein Duplikat von # 11901 zu sein, das leider geschlossen und zum Schweigen gebracht wurde. Dies ist für Deno wichtig, wie bereits gesagt, und ich hoffe, dass TypeScript diese Erweiterungsprüfung konfigurierbar macht oder sie sogar noch besser vollständig entfernt.

In den meisten Javascript-Tooling-Ökosystemen können Sie Dinge wie import picture from 'image.png' tun, was offensichtlich kein Javascript ist. Die Annahme ist, dass einige Tools wissen, wie die referenzierte Datei in Javascript transpiliert wird, damit dies korrekt funktioniert. Alle Arten von Assets und alternativen Syntaxen wie JSX funktionieren auf diese Weise.

Typescript hingegen erwartet, dass Sie entweder eine leere Erweiterung oder die Erweiterung .js , die sich von der Funktionsweise des restlichen Ökosystems unterscheidet. Dies führt zu Reibungsverlusten bei Tools wie Deno oder rollup.js, die die ursprüngliche Dateierweiterung erwarten.

Wenn tsc mehr wie der Rest der Welt arbeiten wollte, könnte es .ts als Erweiterung zulassen und diese dann als Teil der Stripping-Typen zur Erstellungszeit in .js umwandeln. Dies ist offensichtlich eine große Änderung in der Funktionsweise des tsc-Compilers. Auf der anderen Seite gibt es eine Welle alternativer Werkzeuge, die darauf basieren, dass Babel und Sucrase in das Ökosystem eindringen. Vielleicht ist es also ein langfristiger Vorteil, sich an der Art und Weise auszurichten, wie diese Werkzeuge Dinge tun.

Ich füge hier meine Stimme für die Unterstützung von Deno hinzu. Das aktuelle Verhalten führt dazu, dass TypeScript alle auf diese Weise importierten Typen in any auflöst, was die Entwicklung von Software für Deno ziemlich schwierig macht.

Deno ist eine großartige Idee, aber der Versuch, das TS-Team davon zu überzeugen, Deno ausdrücklich zu erlauben, Module auf diese Weise für mich aufzulösen, ist ein verlorener Kampf. Für Deno ist es viel einfacher, damit umzugehen, weil (a) viel schneller, weniger Aufwand erforderlich und (b) das TS-Team davon zu überzeugen, seine Interna so neu zu verdrahten, ein sehr harter Kampf ist.

Wenn tsc mehr wie der Rest der Welt arbeiten wollte

TS wird immer dominanter. Es ist eine gute Strategie, mit den TS-Konventionen einschließlich ihrer Werkzeuge so kompatibel wie möglich zu sein. Andernfalls werden Projekte wie Deno aufgrund der Divergenz in etwas so Grundlegendem wie der Modulauflösung niemals Anklang finden

@ jpike88 Ich bin anderer Meinung. Ich wusste nicht, dass dieses Problem besteht. Es gab ein paar andere Probleme, die teilweise im Zusammenhang standen und die wir verfolgten. Diese Ausgabe sagt nichts über die Absicht des Teams aus. Es ist immer noch als Frage gekennzeichnet und es könnte argumentiert werden, dass es wirklich ein Duplikat von # 16577 oder # 18442 ist.

Ryans Kommentar bringt das Problem auf den Punkt, dass sie möglicherweise etwas aufschreiben können, das jeden Host zufriedenstellt, und beschränken es daher auf die heute häufigste Situation, die Node.js CJS-Methode ist.

Ich denke immer noch (und ich dachte, ich habe dies bereits in einer Ausgabe gesagt), dass es Zeit für "moduleResolution": "literal" die das tun, was es verspricht, und TypeScript erlauben, anzunehmen, dass jeder Laufzeit-Host es herausfinden würde Modulspezifizierer austauschen.

OK aber:

https://github.com/microsoft/TypeScript/issues/18442
Ich habe das tatsächlich wie vor zwei Jahren kommentiert, und es ist nach all dieser Zeit immer noch ein Vorschlag der Stufe 1.

https://github.com/microsoft/TypeScript/issues/16577
Ebenfalls über zwei Jahre alt, noch in der Diskussionsphase. Auch bei der Geschwindigkeit, mit der es geht, passiert es nicht so schnell.

Ich gehe nur von der Zeitskala ab, in der die Dinge hier passiert sind, und begründe ihre Wahrscheinlichkeit, dass dies jemals in einem mittel- oder sogar langfristigen Zeitrahmen geschieht.

Dieses Problem wurde als "Frage" markiert und hat in letzter Zeit keine Aktivitäten erfahren. Es wurde automatisch für Haushaltszwecke geschlossen. Wenn Sie immer noch auf eine Antwort warten, sind Fragen normalerweise besser für den Stapelüberlauf geeignet.

Ein ähnliches Problem tritt auf, wenn Sie eine .mjs -Datei direkt importieren möchten
zB import { forEach } from https://unpkg.com/[email protected]/index.mjs

Dies ist geschlossen, aber nicht behoben.

Wenn jemand hier nur nach einer Möglichkeit gesucht hat, Ihr TypeScript sowohl im Kontext von Node.js als auch von Deno auszuführen, sollten Sie wissen, dass Sie mit Webpack + ts-loader ".ts" in Ihren Importen behalten können.

Ich habe dieses Problem, wenn ich eine Datei aus deno importiere. Gibt es eine Lösung, um dies zu beheben, außer // @ts-ignore hinzuzufügen?

Ist das behoben? Das Importieren ohne Erweiterung ist sowieso nicht Teil des JS. Die Verwendung von Erweiterungen sollte keinen Fehler anzeigen.

Ich stimme den obigen Kommentaren zu. Es ist schade, dass das Problem noch nicht gelöst wurde.
Ich habe eine Erweiterung für vscode gefunden, die helfen sollte, aber leider funktioniert sie nicht richtig.
Wie auch immer, ich werde die Links hier lassen:
1) https://github.com/justjavac/vscode-deno
2) https://github.com/axetroy/vscode-deno

Folgen @ TicTak21 :
Die von ihm erwähnten Links sind jetzt beide zugunsten des offiziellen Deno-Plugins veraltet:
https://github.com/denoland/vscode_deno
Diese Erweiterung behebt die .ts- und URL-Importe (also keine Fehler mehr) korrekt.

@danbulant Ich

Ich benutze auch Deno, aber ich denke, das Problem hier ist nicht .ts vs no .ts . Es geht mehr um die Möglichkeit, tsc zu erlauben, eine Fehlernummer zu ignorieren. Zum Beispiel so etwas wie tsc --ignore TS2691 .

Die Deno-Erweiterung für vs-Code ist nett, löst aber das Problem nicht, sondern unterdrückt nur den Fehler im Editor. Ich habe eine Bibliothek, die ich für deno und den Browser erstellen möchte, aber ich kann nicht, weil tsc werfen wird.

@samuelgozi
Ich stimme zu 100% zu%. Dies ist der Hauptgrund, warum ich Deno noch nicht als Ersatz für node.js auf dem Server betrachte. Ein gutes Web-Framework für Deno ist bereits verfügbar, und nur TYPESCRIPT steht diesem schönen Traum im Wege

Für alle, die kürzlich Probleme damit hatten, werde ich sagen, dass das deno_ls_plugin trotz Archivierung genau das Ergebnis erzielt hat, das ich brauche. In diesem Problem, das auf das Plugin verweist, habe ich davon erfahren .

Mein spezieller Anwendungsfall ist, dass ich in einer Umgebung mit Typoskript-Code arbeite, der zwischen dem Client und dem Server mithilfe von Symlinks geteilt wird. Der Server wurde unter Berücksichtigung von Deno geschrieben, und der Client wurde mit regulärem Typoskript und Phaser3 geschrieben. Der von mir verwendete Bundler, paket , kann Typoskripte importieren, die .ts Dateien importieren (zumindest mit parcel-bundler ^1.12.4 ). Damit bleibt die Intelligenz fixiert.

deno_ls_plugin funktioniert hervorragend für mich, da es buchstäblich nur die Modulauflösung von .ts patcht. Perfekt! Das heißt, ich kann den gemeinsam genutzten Code importieren und den gemeinsam genutzten Code mit Deno-Front und vor allem im Kopf schreiben lassen und die Intellisense für die Typoskript-Client-Seite der Dinge patchen.

Für den Anfang habe ich den Befehl yarn add typescript deno_ls_plugin --dev ausgeführt, um es zu installieren. Nachdem ich festgestellt hatte, dass der Intellisense nicht behoben war, bemerkte ich einen winzigen Text am Ende der Readme-Datei von deno_ls_plugin , um die Arbeitsbereichsversion von Typoskript zu verwenden .

Für alle anderen, die etwas verwirrt darüber sind, habe ich Folgendes getan:
Zuerst habe ich deno_ls_plugin und typescript als Entwicklungsabhängigkeiten installiert und tsconfig.json aktualisiert, um deno_ls_plugin als Plugin aufzunehmen

{
  "compilerOptions": {
    "plugins": [{ "name": "deno_ls_plugin" }]
  }
}

Dann habe ich auf eine Typoskriptdatei geklickt und auf die Version in der unteren rechten Ecke geklickt.

Dann habe ich mich für die Typoskript-Version entschieden

und wählte die Arbeitsbereich-Version.

In meinem speziellen Fall habe ich auch typescript.tsdk auf .vscode/settings.json aber ich weiß nicht, ob ich das tun muss.

Wenn jemand anderes auch versucht, Deno-Code mit Typoskript-Code zu teilen, habe ich Symlinks verwendet, um eine Verknüpfung mit dem Kerncode sowohl auf dem Server als auch auf dem Client herzustellen, und den Code innerhalb des Symlink-Verweises auf eine deps.ts -Datei außerhalb davon verweisen lassen Abhängigkeiten (da import_map irgendwie meh atm ist), damit die Typoskriptversion das npm-Paket und die Deno-Version die URLs importieren kann.

Hoffentlich kann diese kleine Nachricht jedem helfen, der ähnliche Probleme beim Versuch hat, Deno-Code zwischen einem klassischen Typoskript-Projekt und einem Deno-Projekt zu teilen.

Ich habe einen Vorschlag Problem hier , dass das oben beschriebene Problem lösen würde. Hoffentlich können wir in naher Zukunft etwas Schwung bekommen, um dies oder ähnliches umzusetzen.

Dieses Problem muss erneut geöffnet werden.

Die Deno-Entwickler bekommen hier nicht den Respekt, den sie verdienen. Sie haben eine erstaunliche Laufzeit basierend auf TypeScript erstellt, aber TypeScript-Entwickler werden kein Flag hinzufügen, damit es ordnungsgemäß funktioniert. Wie kann diese traurige Situation so lange dauern?!

Die Nichtverwendung der Erweiterung .ts für Importe verursacht den Deno-Benutzern massive Schmerzen und Probleme. Bitte helfen Sie uns!

Es ist nicht wirklich Deno-spezifisch

Ohne die Möglichkeit, die Erweiterung explizit zu definieren, haben viele JS-Entwickler Probleme

Zum Beispiel geben wir in unserem vue -Projekt immer Erweiterungen an, oder wir haben Probleme in Situationen wie

./component.vue
./component.ts

import component from './component';

Warum ist das geschlossen? Sicherlich nicht Deno-spezifisch, besonders mit dem Aufstieg von mjs

Dieser Thread ist KEINE Frage, sondern eine Funktionsanforderung. Kann jemand das Etikett korrigieren und erneut öffnen? Das manuelle Hinzufügen von // @ts-ignore zu jedem Import ist keine akzeptable Lösung.

@zraineri

Ich habe mehrere Threads gelesen, die sich mit diesem Problem befassen. Zusammenfassend lässt sich sagen, dass Kernentwickler dies einfach nicht tun möchten. Sie sagen, dass es andere Dinge kaputt machen kann und dass der Importalgorithmus bereits ziemlich komplex ist und so weiter.

Betrachten Sie mich als verrückt, aber es scheint mir, dass hier eine gewisse Unternehmenssolidarität bestand. Das Unternehmen hat viel Geld für den Knoten (npm) ausgegeben. Und möchte nicht, dass ein Emporkömmling sie mit ihren eigenen Händen ihrer Gewinne beraubt. Ich glaube also nicht, dass man von vscode oder Typoskript viel Freundlichkeit gegenüber Deno erwarten kann

Glücklicherweise können Sie ein Plugin verwenden, das bereits mehr kann, als Sie verlangen, und nur besser wird.
https://marketplace.visualstudio.com/items?itemName=denoland.vscode-deno

Das Problem ist aber nicht nur Deno, sondern auch reguläre js
https://github.com/microsoft/TypeScript/issues/27481#issuecomment -664401169

@ Hulkmaster

Es sieht so aus, als bräuchten wir ein glänzendes neues Typoskript. Dieser steckt mit seinen alten Problemen fest und kann (oder will) keine Importe mit Erweiterungen implementieren. Das Deno-Team scheint zu planen, ein eigenes Typoskript zu schreiben (in Rost, nehme ich an :)

Ich bin Teil des Deno-Kernteams. Ich bin damit einverstanden, dass der TypeScript-Compiler nicht in das Umschreiben von Modulspezifizierern involviert sein sollte. Die Interna von Deno unterdrücken diese Diagnosemeldung und das vscode-Plugin für Deno unterdrückt diese Meldung ebenfalls. Dies ist keine Barriere für Deno.

Vertrauen Sie mir, dass es keine versteckten Kabalen von Microsoft / Node.j gibt, die Deno unterdrücken. Das TypeScript-Kernteam, Mitglied der Node.js-Community und das Deno-Kernteam sprechen regelmäßig miteinander und arbeiten zusammen.

@ Kitsonk

Dies ist keine Barriere für Deno.

Dies ist jedoch ein Hindernis für die Vereinigung zweier Welten: Node und Deno. Wie kann ich ein Typoskript schreiben, das auf beiden Plattformen gleichzeitig funktioniert, wenn Sie religiöse Meinungsverschiedenheiten über den Import lokaler Dateien mit oder ohne Erweiterungen haben? Ich muss eine Seite auswählen

Wie kann ich ein Typoskript schreiben, das auf beiden Plattformen gleichzeitig funktioniert, wenn Sie religiöse Meinungsverschiedenheiten über den Import lokaler Dateien mit oder ohne Erweiterungen haben?

Das ist wirklich kein Problem mit TypeScript / tsc . Node.js ist sowieso auf dem Weg zu expliziten Modulen, und wie sie damit umgehen, wird sich auf die Modulauflösungsfähigkeiten von tsc auswirken, wie ich vermuten würde. Ich glaube, dass dort weiterhin Gespräche geführt werden, um ESM in Node.js besser unterstützen zu können.

Das zu tun, was dieses Problem nahelegt, würde niemandem wirklich helfen. Eine bessere Lösung des Problems wurde in # 33437 vorgeschlagen.