Verwenden Sie ein anderes Bündelungstool wie Browserify oder Webpack für die generierte Ausgabe? oder erwarten Sie, dass dies direkt auf dem Knoten ausgeführt wird?

Wenn dieses Verhalten beabsichtigt ist, wie können dann die Pfadkarten verwendet werden, um die Relative-Import-Hölle in Verbindung mit node zu lösen?

Nun, und um den Kontext hinzuzufügen, ist "paths" für die Verwendung mit Loadern konzipiert, die im Gegensatz zu Node.js require() eine Neuzuordnung zulassen. Das beabsichtigte Verhalten besteht darin, TypeScript zu ermöglichen, Typinformationen für verschiedene Modul-IDs aufzulösen, die von verschiedenen Ladeprogrammen verwendet werden, und nicht, Modul-IDs neu zu schreiben. Im Grunde tut es nicht das, was Sie dachten. Sollte meiner Meinung nach auch nicht sein, es sollte nur die Fähigkeit haben, die Auflösungsstrategien von Loadern zu spiegeln.

@mhegazy Ich hatte erwartet, dass es direkt mit dem Knoten funktioniert. Es ist für eine Backend-Anwendung. Behauptet @kitsonk richtig, dass dies wie beabsichtigt funktioniert und Typoskript Modulpfade nicht umschreibt?

Ja, das war die Absicht - um die Diskrepanz zwischen Laufzeit- und Entwurfszeiterfahrung zu mildern, wenn ein Modul (wie es vom Benutzer geschrieben wird) in der Laufzeit aufgelöst werden kann, aber vom Compiler nicht gefunden werden kann. An diesem Punkt geht der Compiler immer davon aus, dass die vom Benutzer angegebene Modul-ID korrekt ist, und versucht nie, sie zu ändern.

ähnliche Antwort https://github.com/Microsoft/TypeScript/issues/9910#issuecomment -234729007

OK, danke. Es könnte nützlich sein, dies besser zu dokumentieren, um zu verhindern, dass mehr Menschen verwirrt werden. Ich verwende jetzt https://www.npmjs.com/package/module-alias , damit es mit node.

Um die Position von TS zu schätzen, hier ist eine einfache Lösung für den 90%igen Anwendungsfall für diejenigen von uns, die node verwenden, aber die Bequemlichkeit wünschen, baseUrl relative require() Aufrufe ohne viel Aufhebens zu verwenden.

Diese Lösung verknüpft den require() -Aufruf des Knotens und löst Anforderungen unter Verwendung des Verzeichnisnamens „main“ auf, um baseUrl nachzuahmen. Es wird daher davon ausgegangen, dass die Compiler-Option baseUrl auch auf dasselbe Verzeichnis gesetzt wurde, in dem sich die Quelle "main.ts" befand.

Fügen Sie zur Verwendung dieses winzige Stück Code oben in Ihre "main.ts" ein.

import * as path from 'path'
import * as fs from 'fs'
(function() {
  const CH_PERIOD = 46
  const baseUrl = path.dirname(process['mainModule'].filename)
  const existsCache = {d:0}; delete existsCache.d
  const moduleProto = Object.getPrototypeOf(module)
  const origRequire = moduleProto.require
  moduleProto.require = function(request) {
    let existsPath = existsCache[request]
    if(existsPath === undefined) {
      existsPath = ''
      if(!path.isAbsolute(request) && request.charCodeAt(0) !== CH_PERIOD) {
        const ext = path.extname(request)
        const basedRequest = path.join(baseUrl, ext ? request : request + '.js')
        if(fs.existsSync(basedRequest)) existsPath = basedRequest
        else {
          const basedIndexRequest = path.join(baseUrl, request, 'index.js')
          existsPath = fs.existsSync(basedIndexRequest) ? basedIndexRequest : ''
        }
      }
      existsCache[request] = existsPath
    }
    return origRequire.call(this, existsPath || request)
  }
})()

Wenn Sie das von mika-fischer erwähnte Paket module-alias verwenden, beachten Sie, dass die Pfade, die Sie für das Paket registrieren, nicht mit / enden sollten und dass die Pfade relativ zum Pfad sind wo package.json ist (es mag offensichtlich sein, aber es ist gut, es klar zu machen),

Also, wenn Sie dies in Ihrer tsconfig-Datei haben:

"outDir": "./dist",
"baseUrl": ".",
"paths": {
  "foo/*": ["./src"]
}

Sie müssen dies in Ihrem package.json registrieren:

"_moduleAliases": {
  "foo": "dist"
}

Nun, und um den Kontext hinzuzufügen, ist "Pfade" für die Verwendung mit Ladeprogrammen konzipiert, die eine Neuzuordnung ermöglichen, im Gegensatz zu Node.js require(). Das beabsichtigte Verhalten besteht darin, TypeScript zu ermöglichen, Typinformationen für verschiedene Modul-IDs aufzulösen, die von verschiedenen Ladeprogrammen verwendet werden, und nicht, Modul-IDs neu zu schreiben. Im Grunde tut es nicht das, was Sie dachten. Sollte meiner Meinung nach auch nicht sein, es sollte nur die Fähigkeit haben, die Auflösungsstrategien von Loadern zu spiegeln.

Ich bin hierher gekommen, nachdem ich einige Zeit damit verschwendet hatte, es in einem großen Projekt einzurichten.
Wenn sich dieses Verhalten nicht ändern wird, ist das Mindeste, was Sie tun können, die Dokumentation zu aktualisieren, bevor Sie dieses Problem schließen.
Die offizielle Dokumentation https://www.typescriptlang.org/docs/handbook/module-resolution.html#path -mapping%20docs sagt nichts darüber aus, dass "Loader, die eine Neuzuordnung zulassen" verwendet werden müssen.

Installieren und führen Sie "tspath" in Ihrem Projektordner aus ... https://www.npmjs.com/package/tspath

@ef-carbon/tspm

Sie können auch "momothepug/tsmodule-alias" versuchen, um die Pfadauflösung zu aliasieren:

https://www.npmjs.com/package/@momothepug/tsmodule -alias

Nur https://www.npmjs.com/package/module-alias hat bei mir funktioniert ...

Auch ich habe es geschafft, dies mit module-alias zum Laufen zu bringen, mit dem Nachteil, dass ich meine Aliase sowohl innerhalb von tsconfig.json als auch von package.json im Auge behalten muss. Hat jemand eine einfachere Lösung gefunden?

Die von @mattyclarkson aufgezeigte Lösung funktioniert auch, aber ich konnte keine Möglichkeit finden, sie Seite an Seite mit ts-node zu verwenden. Irgendwelche Ideen?

Schauen Sie sich https://github.com/momoThePug/tsmodule-alias an

2018-05-31 15:04 GMT-05:00 edufschmidt [email protected] :

Ich habe es auch geschafft, dies mit dem Modul-Alias ​​zum Laufen zu bringen, mit der Kehrseite
dass ich meine Aliase sowohl in tsconfig.json als auch im Auge behalten muss
Paket.json. Hat jemand eine einfachere Lösung gefunden?

Die von @mattyclarkson aufgezeigte Lösung
https://github.com/mattyclarkson funktioniert auch, aber ich konnte keinen Weg finden
es Seite an Seite mit ts-node zu verwenden. Irgendwelche Ideen?

—
Sie erhalten dies, weil Sie kommentiert haben.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/Microsoft/TypeScript/issues/10866#issuecomment-393662306 ,
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/ACKT9JWIkb0Wekz0H_Z3zKXvoE-49EIBks5t4EzkgaJpZM4J6vZQ
.

Danke @DanyelMorales , das ist wirklich praktisch.

gern geschehen! :)

2018-05-31 16:35 GMT-05:00 edufschmidt [email protected] :

Danke @DanyelMorales https://github.com/DanyelMorales , das ist wirklich
praktisch.

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/Microsoft/TypeScript/issues/10866#issuecomment-393688075 ,
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/ACKT9GNo30wNv4ZWzSwm_Lv4vesLPI3xks5t4GIzgaJpZM4J6vZQ
.

Kann mir jemand sagen, was der Sinn dieser Funktion ist, wenn die ausgegebenen Pfadnamen tatsächlich falsch sind? Das heißt, wenn der TypeScript-Compiler damit zufrieden ist, das Endergebnis jedoch nicht lauffähig ist – was ist der Anwendungsfall für diese Funktion?

Wie sollte man eine relative Pfadzuordnung für Dinge durchführen, die KEINE Module sind, dh keine Importe?

In einem Knotenskript, das ein bestimmtes Verzeichnis relativ zur Quelldatei liest, habe ich Folgendes getan:

const starterDir = path.resolve(__dirname, './templates/starter')

Da typescript das Skript kompiliert und in ein anderes Verzeichnis schreibt (basierend auf config), führt __dirname nicht mehr zur Auflösung des obigen Pfads. Was wäre eine Lösung dafür?

Wie sollte man eine relative Pfadzuordnung für Dinge durchführen, die KEINE Module sind, dh keine Importe?

Das ist wirklich "Wie verwende ich Node.js und TypeScript-Frage" und viel besser in Gitter.im oder StackOverflow gestellt.

Ich liebe TypeScript, aber das ist Wahnsinn.

Ich verstehe es nicht. Auch wenn ich wenig über die TS-Codebasis weiß, sollte dies nicht schwer zu implementieren sein. Ich habe gerade angefangen, ein gemeinsam genutztes Projekt mit Client und Server zu verwenden ... warum präsentiert TS überhaupt die Pfadfunktionalität und lässt mich dann durch Reifen springen, um sie tatsächlich zu verwenden? Warum geht TS davon aus, dass ich bei jedem meiner Projekte einen Bundler/Loader verwenden möchte? Ich versuche, TS zu verwenden, um meine Projekte zu vereinfachen, und nicht mehr Werkzeugbibliotheken hinzuzufügen, um eine zu 90 % implementierte TS-Funktion zu kompensieren.

Ich stimme mit Ihnen ein. Ich denke, TS wurde für Frontend entwickelt, weil Webpack
implementiert schon recht gut ts Alias-Pfade, und mit Requirejs geht das auch
das gleiche. Aber für Nodejs-Projekte ist es so schwierig. :(

El jue., 20. Sept. de 2018 02:50, Josh Pike [email protected]
Beschreibung:

Ich verstehe es nicht. Auch wenn ich wenig über die TS-Codebasis weiß, dies
sollte nicht schwer umzusetzen sein. Ich habe gerade angefangen, ein freigegebenes Projekt zu verwenden
mit Client und Server ... warum präsentiert TS die Pfadfunktionalität in
der erste Platz, lässt mich dann durch Reifen springen, um es tatsächlich zu benutzen? Warum
geht TS davon aus, dass ich bei jedem Projekt einen Bundler/Loader verwenden möchte?
machen? Ich versuche, TS zu verwenden, um meine Projekte zu vereinfachen, nicht mehr anzuheften
Werkzeugbibliotheken, um eine zu 90 % implementierte TS-Funktion zu kompensieren.

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/Microsoft/TypeScript/issues/10866#issuecomment-423077950 ,
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/ACKT9DD_z4KOHpfwddTomMXujEsza9tQks5uc0jbgaJpZM4J6vZQ
.

+1!

Webpack kann mir helfen, Pfadkarten (oder andere Tools wie babel-plugin-module-resolver ) aufzulösen, aber keine Deklarationen ( .d.ts ) .

Alle Pfade in der Deklaration werden nicht aufgelöst.

Bin auch auf dieses Problem gestoßen. Es schien logisch, dass der ausgegebene Code Pfadzuordnungen enthalten würde. Auf Modul-Alias ​​zurückgegriffen. Aber +1 für Typescript, um diese Funktionalität optional bereitzustellen.

Kann dies nicht einfach als Compiler-Option hinzugefügt werden? Offensichtlich ist es eine beliebte Anfrage. Wenn Sie nichts über die Funktionsweise des Compilers wissen, sollte die Implementierung nicht super einfach sein? Warum uns zwingen, woanders durch die Reifen zu springen, wenn es so einfach direkt mit dem TypeScript-Compiler gelöst werden kann, wo es am sinnvollsten ist?

+1

Mit ts-transformer-imports und ttypescript können Sie absolute und pfadbasierte TypeScript-Importe in relative Javascript-Dateien kompilieren

Ich habe eine Kompilierungslösung erstellt, bei der Sie weiterhin tsc verwenden können. https://github.com/joonhocho/tscpaths

Microsoft/TypeScript#15479 (Kommentar)

Ich bin gerade von diesem Problem betroffen, als ich versuchte, vue-cli dazu zu bringen, d.ts-Dateien auszugeben, in denen viele import {foo} from "@/some/folder/foo" vorhanden sind und die ausgegebenen d.ts-Dateien den Alias ​​nicht auflösen.

Aus der allgemeinen Suche und dem Durchsehen dieses Threads und anderer geht hervor, dass die reflexartige Reaktion "dies ist kein Problem, das TS lösen muss" lautet, aber ich würde das Team bitten, diese Haltung wie derzeit zu ändern, wenn Sie einen benutzerdefinierten Pfadalias verwenden (vollständig gültig und empfohlener Ansatz für komplexe Projekte) können Sie einfach keine d.ts-Dateien generieren (ohne einen benutzerdefinierten Build-Prozess eines Drittanbieters) verwenden, daher würde ich sagen, dass der Typescript-Compiler diese Aliasnamen auch im Deklarationsdateiprozess auflösen sollte.

Die Aufgabe des Compilers besteht darin, gültige Javascript- UND d.ts-Dateien für Ihre Typoskript-Dateien auszugeben, und es funktioniert einfach nicht in diesem gültigen Szenario (unter Verwendung von Pfadaliasnamen in tsconfig-Dateien).

Ich bin bei diesem Thema etwas verwirrt. Es wurde geschlossen und mit „Funktioniert wie vorgesehen“ gekennzeichnet. Soll ich verstehen, dass Typescript ungültige Quellen ausgeben soll? Scheint seltsam.

Bettler können nicht wählerisch sein, aber die Verwendung von Typescript vermeidet viele frustrierende Aspekte von Vanilla JS, und ich zähle relative Importe ('../../../../../utils/parser') zu ihnen. Es wäre erstaunlich, wenn Typescript diese bereinigen könnte!

@codeitcody Scheint so. Es ist dumm, dass es etwas ausgeben würde, das ohne ein Paket eines Drittanbieters einfach nicht funktioniert, aber das ist die Realität.

Nun, ist das nicht ein nettes Problem, auf das man stoßen kann?

Es scheint sehr kontraproduktiv zu sein, eine Funktion zu haben, die Ihre App im Wesentlichen unbrauchbar macht, ohne durch Reifen zu springen (dh mehr Abhängigkeiten zu installieren, um das Problem zu umgehen).

Dieses Problem besteht seit 2 Jahren und es gibt kein offizielles Wort darüber, ob es implementiert wird oder nicht.

Wenn man bedenkt, dass dies eine erforderliche und grundlegende Funktionalität ist, um eines der besten Features von TypeScript in Ihren Node.js-Projekten zu verwenden, ist es ziemlich schrecklich, wie es behandelt wird.

@mhegazy Können Sie oder jemand anderes uns mitteilen, ob das TypeScript-Team jetzt zwei Jahre später vielleicht noch einmal einen Blick darauf werfen und es sich noch einmal überlegen würde?

Webpack kann mir helfen, Pfadkarten (oder andere Tools wie babel-plugin-module-resolver ) aufzulösen, aber keine Deklarationen ( .d.ts ) .

Alle Pfade in der Deklaration werden nicht aufgelöst.

Gibt es eine Möglichkeit, dies zu erreichen? Ich habe eine benutzerdefinierte Reaktionskomponentenbibliothek und ich habe diesen Fehler erhalten, als ich versuchte, paths für einen Alias ​​zu verwenden. Ich mache die 2 Bundles mit Rollup und die Typen mit --emitDeclarationOnly

Ich kann Modul-Alias ​​nicht verwenden, weil es sagt:

WARNUNG: Dieses Modul sollte nicht in anderen npm-Modulen verwendet werden, da es das standardmäßige Anforderungsverhalten modifiziert!

Bitte helfen Sie, diesen Beitrag auf Reddit zu verbessern: https://www.reddit.com/r/typescript/comments/a07jlr/path_maps_cannot_be_resolved_by_tsc_works_as/
Verstehe nicht warum hier diese große Diskussion nötig ist. Es sollte einfach sein, diesen Fehler zu beheben. Eine Option in tsconfig und jeder kann entscheiden, ob er das aktuelle Verhalten (aus welchen Gründen auch immer) oder einen funktionierenden Ansatz haben möchte.

Wir hatten das gleiche Problem bei Dropbox und haben diesen Transformer https://github.com/dropbox/ts-transform-import-path-rewrite als Open-Source bereitgestellt

Ich habe jetzt mehrmals die gleiche Erfahrung gemacht, ich erwarte, dass der Pfadalias aufgelöst wird, aber ich vergesse immer wieder, dass ich module-alias installieren, package.json aktualisieren und in die Hauptdatei importieren muss. Wäre großartig, wenn dies im Kompilierungsschritt von Typescript behandelt würde.

Autsch. Dies ist ein echter Schlag für TypeScript. Wo ist da der Sinn?

ps Können wir nicht einfach +1 kommentieren

Willkommen im Club @def14nt. Wir sind eine glückliche Gruppe von Träumern, die mit strahlenden Augen in eine bessere Zukunft blicken und geduldig auf den Tag warten, an dem TypeScript die einfache und vernünftige Compiler-Option implementiert, um unser Leben einfacher zu machen. Wenn dieser Tag endlich vor uns liegt, achten Sie darauf, den Himmel nach den dicken rosa Körpern der Schweine zu durchsuchen, die majestätisch auf ihren neu entdeckten Flügeln in den Sonnenuntergang davonfliegen.

Lol, ich installiere einfach eine npm-Erweiterung für etwas, für das das TypeScript-Team Unterstützung hinzufügen könnte. Vielleicht sollten sie aufhören, immer mehr Verbesserungen hinzuzufügen und Funktionen hinzufügen, die so grundlegend sind.

@mika-fischer
Wie verwende ich https://www.npmjs.com/package/module-alias , damit eslint aufhört, vor „Unresolved path ‚@root/bla/bla‘ (in JS-Dateien)“ zu warnen? Und wie aktiviert man die automatische Vervollständigung für solche Pfade in WebStorm und VS Code?

Für mich funktioniert die automatische Vervollständigung von Importen in VSCode standardmäßig in Typoskript-Projekten.

@bobmoff Ja, scheint alles gut zu sein, um TS-Dateien aus TS-Dateien zu importieren.
Aber die automatische Vervollständigung und Navigation für `require('@root/bla/bla') von TS-Dateien funktioniert nicht.

Ich möchte mein JS-Projekt in TS übersetzen und dachte, dass ich js-Dateien einzeln in ts umbenennen kann.
Jetzt ist mir klar, dass es so schwer ist und weder von ts noch von IDEs unterstützt wird, und ich sollte alle meine js-Dateien auf einmal in ts umbenennen.

Denn wenn ich nur eine JS-Datei in TS umbenenne, wurden alle relativen Pfade im Verzeichnis build kaputt (wahrscheinlich sollte ich "allowJs: true" verwenden, aber ich habe ein Projekt mit 2 Gigabyte JS-Dateien, es ist so seltsam, sie in das Build-Verzeichnis zu kompilieren %)).
Ok, ich versuche, dies durch Modul-Aliase zu lösen, und die Navigation und die automatische Vervollständigung meiner IDE funktionieren nicht mehr und eslint warnt vor 100500 'Unresolved Paths'. Ich hasse TS schon ein bisschen, anscheinend ist die Migration für große JS-Projekte nicht so einfach, wie TS-Marketing-Leute sagen. Es scheint, als wäre die Migration von JS-Backend-Projekten nach Golang einfacher :)

Ich verwende erfolgreich tscpaths als Problemumgehung.

Ich auch. Ich kann tscpaths wirklich empfehlen. Es funktioniert wie es soll.

Mein einfacher Workaround:

node -r ts-node/register/transpile-only -r tsconfig-paths/register index.js

Oder mit der pm2 process.yml

apps:
  - name: 'my-app'
    script: './dist/index.js'
    instances: 'max'
    exec_mode: 'cluster'
    out_file : '/dev/null'
    error_file : '/dev/null'
    node_args: ['--require=ts-node/register/transpile-only', '--require=tsconfig-paths/register']
    env_production:
      NODE_ENV: production

Ich bin gerade darüber gestolpert, manchmal kann TypeScript eine echte Nervensäge sein.

Ich verstehe ernsthaft nicht, warum dieser Thread immer weiter und weiter und weiter geht....
Wir alle kennen die „Pfadhölle“ und dass Sie (indem Sie Aliase verwenden) dies können
wirklich sauber
Mach das Chaos auf, jeder in diesem Thread weiß das!

Die Aliase werden vom TypeScript-Compiler interpretiert, er kompiliert exakt
so wie es sollte,
Es sollte auf keinen Fall im resultierenden Javascript herumstochern, wenn
Sie verwenden möchten
Pseudonyme müssen Sie selbst lösen!

....oder starten Sie Threads bei Apple, Google und Microsoft
Bitten Sie sie, die Funktionalität in ihren JavaScript-Engines zu implementieren, damit
Sie können
interpretiere deine Pseudonyme ;-)

Der TypeScript-Compiler tut genau das, was er tun soll!

Wenn Sie in der Angular-Welt arbeiten, ist der Weg gepflastert, wenn Sie möchten
Führen Sie Ihre
Code direkt in Node benötigen Sie ein Tool, um die Pfade aufzulösen, und ich habe
gemacht
ein solches Werkzeug nur für Sie, es wird seit über einem Jahr in der Produktion eingesetzt,
es ist
verwendet von der größten Zeitung hier in Schweden, habe ich dies gemacht, damit Sie es können
nackt gehen
bone with Node, ich versuche hier nichts zu verkaufen, ich verdiene kein Geld
davon :)

Und ja, es gibt Tools wie "tsmodule-alias" und ähnliche Hacks, das können Sie
eigentlich funktionieren lassen
Wenn Sie sehr sehr vorsichtig sind, aber es ist ein Durcheinander, gibt es Problemumgehungen mit
ts-Knoten,
Shell-Skripte usw. usw. ... yadda yadda

Endlich hatte ich das Gefühl, dass genug genug ist, also schloss ich mich ein und machte
TsPfad
die Kompilierzeit-Aliasnamen

> npm install -g tspatj

meinprojekt> tsc

meinprojekt> tspath

oder

meinprojekt> tspath --f

headless (hat sich auf dem Build-Server als sehr nützlich erwiesen)

und dann sind Sie fertig, Ihre Javascript-Dateien haben jetzt die
richtige relative Pfade, wollen wir das hier nicht?

Prost! :)

https://www.npmjs.com/package/tspath

Den Sonntag 13 Jan. 2019 kl 22:20 skrev Fabio Spampinato <
[email protected]>:

Ich bin gerade darüber gestolpert, manchmal kann TypeScript eine echte Qual sein
Arsch.

—
Sie erhalten dies, weil Sie kommentiert haben.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/Microsoft/TypeScript/issues/10866#issuecomment-453866553 ,
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/AAAy_7JYrwYo3KOLxpLWP0np5JVz2kQzks5vC6MogaJpZM4J6vZQ
.

@duffmann

Die Aliase werden vom TypeScript-Compiler interpretiert, er kompiliert exakt
Wie es sich gehört, sollte es auf keinen Fall im resultierenden Javascript herumstochern, wenn
Wenn Sie Aliase verwenden möchten, müssen Sie dies selbst lösen!

Stimme überhaupt nicht zu. Wenn Sie nicht scherzten, konnte ich es wirklich nicht sagen.

TypeScript sollte Code kompilieren, der _funktioniert_, ohne dass ein Drittanbieter-Tool benötigt wird, um den Job abzuschließen, der nur teilweise in den nativen Compiler implementiert wurde.

Der TypeScript-Compiler tut genau das, was er tun soll!

Wenn dieser Thread voller Leute wäre, die verlangen, dass tsc auch eine Verkleinerung oder ähnliches durchführt, würde ich Ihnen zustimmen. Es ist jedoch nicht. Es sind Leute, die verlangen, dass der Compiler ausführbaren Code generiert. Ich glaube wirklich nicht, dass das von einem Compiler zu viel verlangt ist, oder?

Und es generiert ausführbaren Code, wenn Sie die Funktionen nicht verwenden
von JavaScript-Engines nicht unterstützt, sollte das sehr sinnvoll sein
dort zum Beispiel: Würden Sie dem C++-Compiler die Schuld geben, wenn Ihre Anwendung
Dynamic Link Libraries verwendet und dass das Programm nicht auf einer Maschine läuft
das hat diese nicht installiert?

Dies ist eine Funktion, die verwendet werden kann, wenn Sie die relativen Pfade verwalten,
Verantwortung für sie übernehmen, wie es Angular mit WebPack tut oder wie ich mit
alle meine TypeScript-Projekte mit TSPath!

Verwenden Sie sie nicht, wenn Sie nicht verstehen, wie man eine Arbeitsumgebung einrichtet,
Ich glaube wirklich nicht, dass das hier in der Verantwortung von Microsoft liegt, sie
ein Feature bereitgestellt und so funktioniert es,
Es funktioniert möglicherweise nicht so, wie Sie es möchten oder erwarten, dass es funktioniert, aber das macht es nicht
es falsch!

Außerdem bin ich neugierig, ob Sie sich ernsthaft davon abhalten lassen
Entwickeln mit TypeScript?

Am 14. Jan. 2019 kl 21:34 skrev Robert Main [email protected] :

Der TypeScript-Compiler tut genau das, was er tun soll!

Wenn dieser Thread voller Leute war, die darum baten, dass tsc dies auch tut
Verkleinerung oder so, da würde ich dir zustimmen. Es ist jedoch nicht. Es ist
Personen, die verlangen, dass der Compiler ausführbaren Code generiert. Ich [...] wirklich
Denken Sie nicht, dass das von einem Compiler zu viel verlangt ist, oder?

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/Microsoft/TypeScript/issues/10866#issuecomment-454151277 ,
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/AAAy_7FeuOJAnI9bXYSVgf_YghJluTyGks5vDOnEgaJpZM4J6vZQ
.

Dies ist eine Funktion, die genutzt werden kann, wenn Sie die relativen Pfade verwalten, die Verantwortung dafür übernehmen, wie es Angular mit WebPack tut oder wie ich es mit all meinen TypeScript-Projekten mit TSPath tue!

Dies ist eine Funktion, die dazu führt, dass der Compiler fehlerhaften Code ausgibt, Code, der funktionieren könnte, wenn er nur eine Codezeile zum ordnungsgemäßen Auflösen dieser Pfade schreiben würde.

Die Tatsache, dass TS einen externen Bundler benötigt, nur damit der ausgegebene Code ausgeführt werden kann, ist einfach lächerlich.

Und es generiert ausführbaren Code, wenn Sie die Funktionen nicht verwenden
von JavaScript-Engines nicht unterstützt,

Ich habe immer verstanden, dass TypeScript zu JavaScript kompiliert werden sollte. Wenn Sie mir sagen, dass bestimmte Funktionen von JavaScript-Engines nicht unterstützt werden, warum genau sind sie dann da?

Würden Sie dem C++-Compiler die Schuld geben, wenn Ihre Anwendung Dynamic Link Libraries hat und das Programm nicht auf einem Computer läuft, auf dem diese nicht installiert sind?

Nein, aber ich würde es beschuldigen, wenn ich damit ohne Compilerfehler oder Warnung auf anderen C++-Code verlinken könnte, der nicht wirklich existiert.

Du verstehst das wirklich nicht, oder? Der Code ist nicht gebrochen, falls er es ist
defekt ist es, weil Sie den Compiler konfiguriert haben
um Code zu generieren, den Ihre "Plattform" in diesem Fall nicht unterstützt,
Pseudonyme!

Verwenden Sie in Ihrem Fall keine Aliase, "Sie" unterstützen sie nicht, im Ernst!

Auch wenn dies ein 1-zeiliger Fix wäre (das ist natürlich nicht der Fall), ist es ein
Frage, was ein Compiler sollte und
sollte nicht tun! Diese Funktion wurde hinzugefügt, um LOADERS nicht zu UNTERSTÜTZEN
umgekehrt nachlesen
on Path Mapping in der offiziellen Dokumentation, Sie verwenden es also erneut
falsch!

Auch dieses Feature ist für Loader/Resolver, Sie haben es missverstanden
funktioniert, also nein, Microsoft
sollte den Compiler nicht so ändern, dass Sie Aliase ohne einfügen können
Umgebung, die es unterstützt!

Den tis 15 jan. 2019 kl 04:41 skrev Fabio Spampinato <
[email protected]>:

Dies ist eine Funktion, die verwendet werden kann, wenn Sie die relativen Pfade verwalten,
Verantwortung für sie übernehmen, wie es Angular mit WebPack tut oder wie ich mit
alle meine TypeScript-Projekte mit TSPath!

Dies ist eine Funktion, die den Compiler dazu bringt, fehlerhaften Code auszugeben, Code that
könnte funktionieren, wenn sie nur 1 Codezeile zur Lösung dieser Probleme schreiben würden
Pfade.

Die Tatsache, dass TS einen externen Bundler benötigt, ist nur damit der ausgegebene Code
ausgeführt werden kann, ist einfach lächerlich.

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/Microsoft/TypeScript/issues/10866#issuecomment-454256799 ,
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/AAAy_zuWKV0qzzWt6_jZNgDLFt1TA0tMks5vDU3vgaJpZM4J6vZQ
.

Sie sind da, da Loader Path Mapping verwenden, deshalb wird es unterstützt!
Und da Sie (wie ich) darauf bestehen, sie ohne Loader zu verwenden, was ist das
Problem mit
Verwenden Sie ein Tool, damit Sie die Funktion nutzen können?

Den tis 15 jan. 2019 kl 05:10 skrev Robert Main [email protected] :

Und es generiert ausführbaren Code, wenn Sie die Funktionen nicht verwenden
von JavaScript-Engines nicht unterstützt,

Ich habe immer verstanden, dass TypeScript kompilieren sollte
JavaScript. Wenn Sie mir mitteilen, dass bestimmte Funktionen nicht von unterstützt werden
JavaScript-Engines, warum genau sind sie dann da?

würden Sie den C++-Compiler beschuldigen, wenn Ihre Anwendung dynamisch verknüpft ist
Bibliotheken und dass das Programm nicht auf einer Maschine läuft, die diese nicht hat
Eingerichtet?

Nein, aber ich würde es beschuldigen, wenn ich damit auf anderen C++-Code verlinken könnte, der dies nicht tat
existieren tatsächlich ohne Compilerfehler oder Warnung.

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/Microsoft/TypeScript/issues/10866#issuecomment-454260977 ,
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/AAAy_25-ZmS235i1Ic7mvSzEt2QJDX6Bks5vDVTAgaJpZM4J6vZQ
.

Schau, ich verstehe deinen Punkt. Ich mache. Aber ein Teil der Arbeit des Compilers besteht darin, die Dinge ein letztes Mal auf Plausibilität zu prüfen. Im besten Fall ist Code, der kompiliert, aber nicht ausgeführt wird, ein inkonsistentes Verhalten, und als ich zum ersten Mal in dieses Problem las, schien die Dokumentation ein Verhalten vorzuschlagen, das eindeutig nicht vorhanden ist

Bitte verweisen Sie mich auf diesen Abschnitt der Dokumentation.

es ist der 15. jan. 2019 k. 05:31 skrev Robert Main [email protected] :

Schau, ich verstehe deinen Punkt. Ich mache. Aber ein Teil der Arbeit des Compilers ist die Vernunft
überprüfen Sie die Dinge ein letztes Mal. Bestenfalls Code, der kompiliert, aber nicht ausgeführt wird
inkonsistentes Verhalten und als ich zum ersten Mal in dieses Problem las
Die Dokumentation schien ein Verhalten vorzuschlagen, das eindeutig nicht vorhanden ist

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/Microsoft/TypeScript/issues/10866#issuecomment-454263854 ,
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/AAAy_8e5v8IV-ynmjRTeoC3cp5llwnsIks5vDVm8gaJpZM4J6vZQ
.

Diese Funktion wurde hinzugefügt, um LOADERS nicht zu UNTERSTÜTZEN
umgekehrt nachlesen
on Path Mapping in der offiziellen Dokumentation, Sie verwenden es also erneut
falsch!

https://austinknight.com/wp-content/uploads/2015/04/DesignVSUX.jpeg

@duffman Siehst du nicht, dass die Leute hier nur diese Funktion wollen??? Sie sagen jedem, dass er/sie zu dumm ist, um zu verstehen, wie dieses "Feature" verwendet werden sollte. OK - so kann man das sehen, aber wer weiß - vielleicht ist es auch umgekehrt...

Meine Meinung ist übrigens folgende:

Da Aliase im Compiler eingebaut sind und die Kompilierung des Projekts mit ihnen in Ordnung ist. Es könnte Benutzer denken lassen, dass es so funktioniert, wie es vorschlägt (und dieses Problem ist ein ziemlich guter Beweis dafür, dass ich Recht habe). Es scheint sogar unlogisch - warum funktioniert etwas im "offiziellen" Editor (vscode - insbesondere bei Verwendung der Funktion "Auto-Import", vscode verwendet Alias-Pfade), warum funktioniert der Copiler auch OK, wenn der resultierende Code nicht funktioniert? Wenn ich sage "JS-Engine unterstützt es nicht", möchte ich noch mehr fragen - war TS nicht dazu gedacht, einige der JS-"Probleme" zu mildern?

Ich würde eine von zwei Lösungen davon erwarten:
1) Korrektes Überschreiben von Importen mit Aliasen
2) Anzeige einer Warnung

Zu sagen "es ist richtiges Verhalten" ist meiner Meinung nach falsch. Es ist nicht. TS ist keine Assemblersprache, nicht einmal C/C++.

Das Entwicklungsteam sollte Unterstützung für die Aliasauflösung hinzufügen. Ich schlage vor, a hinzuzufügen
Schlüssel für Compiler-Auflösung in tsconfig.

Schön wäre Microsoft!!!!!!

Wir bitten Sie, wir brauchen Ihre Hilfe, um Anwendungen mit Alias ​​zu verbessern.

:( Jeder hier ist traurig und wütend (und hungrig) wegen der Verzögerung von
Konsistenz. Typoskript ist großartig, ich liebe es ...

Wir lieben es!

Beste Grüße an einen Homeless-Entwickler ...

El März, 15 de ene. de 2019 08:02, Mike S. [email protected]
Beschreibung:

Meine Meinung ist übrigens folgende:

Aliase sind im Compiler eingebaut, eine Kompilierung ist OK. Es kann Benutzer machen
denken, dass es so funktionieren sollte, wie sie denken (und dieses Problem ist so ziemlich
guter Beweis, dass es wahr ist). Es scheint unlogisch - warum etwas funktioniert
"offizieller" Editor (vscode - insbesondere bei Verwendung der Funktion "Auto-Import",
vscode verwendet einen Alias-Pfad), warum der Copiler auch beim resultierenden Code OK funktioniert
funktioniert nicht? Wenn ich sage "js engine unterstützt es nicht", möchte ich fragen
noch mehr - war TS nicht dazu gedacht, einige der "Probleme" von JS zu mildern?

Ich würde eine von zwei Lösungen davon erwarten:

1. Korrektes Überschreiben von Importen mit Aliasen
2. Warnung anzeigen

Zu sagen "es ist richtiges Verhalten" ist meiner Meinung nach falsch. Es ist nicht. TS ist es nicht
Assemblersprache, nicht einmal C/C++.

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/Microsoft/TypeScript/issues/10866#issuecomment-454384357 ,
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/ACKT9OqexgOaHH1vDFuRcO7U_r2DEC23ks5vDdFbgaJpZM4J6vZQ
.

. TS ist keine Assemblersprache, nicht einmal C/C++.

Ich verstehe wirklich nicht, worauf Sie hinweisen wollen, indem Sie feststellen, dass TS nicht C ++ ist, die meisten von uns sind sich dessen wohl bewusst, denke ich!

Wir haben auch festgestellt, dass Alias/Pfad-Mapping in der Produktion auf der ganzen Welt verwendet wird, also sollte VS Code das natürlich unterstützen, aber es ist immer noch kein Argument für MS, den Compiler so zu gestalten, dass er zu Ihrem Setup passt!

Was ich nur schwer verstehe, ist, warum Sie dabei bleiben, der Compiler funktioniert so, wie er funktionieren soll. Lesen Sie noch einmal die Dokumentation, in der klar angegeben ist, wofür das Feature ist!

Ich meine, Sie können eine funktionierende TS-Entwicklungsumgebung mit Pfadaliasnamen in etwa 2 Minuten einrichten. Wenn Sie WebPack nicht verwenden möchten, können Sie TSPath verwenden, um alle Pfade in allen js-Dateien in 1 Sekunde aufzulösen, und es dem Paket hinzufügen .json als Runscript und Sie müssen nicht einmal darüber nachdenken, das Problem besteht nicht, der Compiler bleibt so, wie er funktionieren sollte, und Sie können fröhlich weitermachen, hurra!?

Oder wenn es Ihnen so wichtig ist, dass der eigentliche Compiler dies für Sie erledigt, dann schlage ich vor, dass Sie den Compiler forken und selbst implementieren, vielleicht wäre es ein großer Erfolg oder vielleicht sind die Leute so glücklich, wie sie sind, seit sie es eingerichtet haben ihre Umgebungen, um Aliase zu unterstützen.

Aufruf der fünf besten TypeScript-Beitragenden: @ahejlsberg @andy-ms @DanielRosenwasser @sandersn @sheetalkamat

Könnte das TypeScript-Team dieses Problem noch einmal überdenken? Ich denke, dieser Thread bietet einige nützliche Diskussionen zu beiden Standpunkten und angesichts seiner jüngsten Popularität und der Zeit, die vergangen ist, sollte er erneut betrachtet werden.

Der Status dieses Problems ließ mir keine andere Wahl, als TS nur auf Typ Checker Duty herabzustufen.
Babel hat jetzt eine anständige Unterstützung für die TS-Syntax und erledigt zusammen mit babel-plugin-module-resolver die Aufgabe, funktionierenden Code für diesen Anwendungsfall gut auszugeben.
Der einzige Nachteil ist das Duplizieren von Konfigurationsteilen von tsconfig.json , da Babel sich nicht um TS-Konfigurationen kümmert. Aber es ist ein akzeptabler Preis für das Arbeiten mit absoluten Pfaden in Node-Projekten und als Bonus bekomme ich das gesamte Ökosystem mit brillanten Dingen wie babel-Makros.

Dies ist die minimale Einrichtung, die ich als Drop-in-Ersatz für den Compiler tsc erhalten habe:

• npm install --save-dev @babel/cli @babel/core @babel/preset-env @babel/preset-typescript babel-plugin-module-resolver @babel/plugin-proposal-class-properties @babel/plugin-proposal-object-rest-spread
• in package.json :
  tsc -> tsc && babel ./src --out-dir ./dist --extensions ".ts,.js"
• in tsconfig.json :

{
  "compilerOptions": {
    "baseUrl": ".",
    "paths": {
      "@mynamespace/*": ["src/*"]
    },
    "outDir": "./dist",
    "noEmit": true, <--
    "allowJs": true,
    "target": "ES2017",
    "module": "CommonJS",
    "lib": [
      "ES2017"
    ]
  },
  "include": [
    "./src/**/*"
  ]
}

• in .babelrc :

{
  "presets": [
    "@babel/preset-typescript",
    ["@babel/preset-env", {
      "targets": {
        "node": true
      }
    }]
  ],
  "plugins": [
    ["module-resolver", {
      "root": ["./src"],
      "alias": {
        "@mynamespace": "./src"
      },
      "extensions": [".js", ".ts"]
    }],
    "@babel/plugin-proposal-class-properties",
    "@babel/plugin-proposal-object-rest-spread"   
  ]
}

Ich möchte nur Typoskript mit absolutem Pfad verwenden, aber anscheinend muss ich Webpack oder Babel oder so konfigurieren, es ist zu schwierig, diese einfache Funktion zu erreichen, es sollte einfacher sein 😞

Ich erkenne dieses Problem an, ich bin mir nicht sicher, ob ich mir dessen bewusst war
Problem aufgrund meiner eigenen persönlichen Einrichtung, oder vielleicht war ich es :) es ist kein Super
schwerer Fix, der Fix besteht einfach darin, dem distPath einfach (blind) zu vertrauen,
das ist eigentlich immer weniger einfacher Code als die aktuelle Lösung, ich werde
Versuche bis morgen eine Lösung zu haben...

Am 28. Jan. 2019 kl 15:59 skrev 叶伟伟[email protected] :

Ich möchte nur Typoskript mit absolutem Pfad verwenden, aber anscheinend muss ich das
config webpack oder babel oder so, es ist zu schwer zu erreichen!!!

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/Microsoft/TypeScript/issues/10866#issuecomment-458164055 ,
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/AAAy_1_T-An7swSND-xdBhL0HNHxQkm6ks5vHxBggaJpZM4J6vZQ
.

Lassen Sie dies hier, weil ein tatsächlich dokumentierter Anwendungsfall für das aktuelle Verhalten von paths in diesem Thread nicht erwähnt wurde: @types/ -Pakete backportieren keine Funktionen in Bezug auf semver. Sie enthalten jedoch aktualisierte Typen für ältere APIs, die ich verwenden kann. ZB verwende ich history@2 , wenn history@3 das neueste ist.

"paths": {
    "history": [ "history/v2" ]
}

Der Compiler würde eine zusätzliche Option benötigen, um zwischen Typaliasen und "Code"-Aliasen zu unterscheiden. Wenn wir das Verhalten ändern, um die Pfadaliasnamen tatsächlich auszugeben, müssen wir dem Compiler die Fähigkeit hinzufügen, die richtige Typversion zu finden.

Dies ist kein Argument gegen das vorgeschlagene Verhalten. Ich hätte lieber Aliase und eine funktionierende Lösung für die Versionierung von Typen ausgegeben. Ich wollte nur einen Kontext liefern, warum das Ändern dieser Änderung möglicherweise nicht so trivial ist, wie die Leute denken, dass es ist.

Zum zweiten Mal musste ich während eines unternehmensweiten TS-Workshops dieses dumme und peinliche Verhalten erklären ...

Ernsthaft!

Welche Art von Sprachcompiler, insbesondere einer, dessen primäres Verkaufsargument mehr Korrektheit für JavaScript ist, produziert fehlerhaften Code als "Feature"?!?!

Es tut mir leid, dass ich in meinem Kommentar so frustriert geklungen habe, aber die Ansichten der Community hier werden anscheinend wiederholt ignoriert und heruntergespielt.

Schauen Sie sich nur an, wie oft darauf verwiesen wurde ... Was für eine Verschwendung von Zeit und Aufmerksamkeit für so viele Menschen.

Ich verstehe Ihre Frustration, aber viele Leute denken, dass ein Verhalten richtig ist, was nicht bedeutet, dass es das Richtige ist.

Das Umschreiben von Modulkennungen in TypeScript ist ein rutschiger, rutschiger Abhang. Was in diesem Thread mehrfach zum Ausdruck gebracht wurde, ist, dass TypeScript so konfiguriert werden kann, dass es das Verhalten anderer Modul-Resolver und anderer Build-Tools modelliert, nicht ersetzt oder implementiert.

Nur weil TypeScript so konfiguriert werden kann, dass es Module auf flexible Weise auflöst, bedeutet das nicht, dass TypeScript „kaputten Code“ ausgibt. Bestimmte Loader und Bundler, die diese Konfiguration widerspiegeln, würden problemlos funktionieren.

Wenn wir irgendetwas kritisieren würden, könnten wir dem Team vorwerfen, dass es die Option so benannt hat, dass es so aussieht, als würde es ein Problem beheben, das nie behoben werden sollte, obwohl die Dokumentation für die Option klar macht, dass es die Emission nicht ändert .

Da ein bestimmtes Tool ein Problem, das Sie haben, nicht löst, bedeutet das nicht immer, dass das Tool schuld ist. Vielleicht haben Sie einfach nicht alle Tools, die Sie zur Lösung Ihres Problems benötigen.

@kitsonk alles, was du gerade gesagt hast, ist weit daneben.

Das Problem ist, dass TS während der Entwicklung/des Testens auf eine Weise arbeitet und nach Abschluss der Kompilierung auf eine andere Weise.

Wenn TS ein Modul-Resolver sein möchte, muss es ein Muster wählen und sich daran halten. Wenn ich etwas mit ts-node ausführe, sollte es genau so funktionieren, als ob ich einige TS kompiliert und mit node ausgeführt hätte.

Das geht nicht und das ist das Problem.

Vielleicht lindern Modulkarten in Zukunft den Frust. Aber unsere Position hier zusammen mit den technischen Problemen, die wir lösen wollen, sind ziemlich eindeutig – die Pfadzuordnung spiegelt das Verhalten eines externen Auflösungsschemas wider (z. B. die Pfadzuordnung in AMD und System.js, Aliase in Webpack und anderen Bundlern). Das bedeutet nicht, dass wir Ihre Wege ändern werden.

Ich glaube nicht, dass eine aktuelle Diskussion in letzter Zeit konstruktiv war, noch sehe ich hier zukünftige Änderungen voraus, also werde ich dieses Thema sperren.