TypeScript 7.0 angekündigt

 (devblogs.microsoft.com)
4 Punkte von GN⁺ 2 시간 전 | 2 Kommentare | Auf WhatsApp teilen
  • TypeScript 7.0 ist eine Release, die die Toolchain in nativen, auf Go basierenden Code portiert. Bei vollständigen Builds großer Projekte bringt sie in der Regel eine 8- bis 12-fache Beschleunigung
  • Das neue tsc wird wie bisher über das npm-Paket typescript installiert, und die Editor-Unterstützung läuft als LSP-basierter Sprachserver in VS Code, Visual Studio, WebStorm und weiteren Umgebungen
  • In Codebasen wie vscode, sentry, bluesky, playwright und tldraw wurden die Build-Zeiten deutlich verkürzt, in manchen Umgebungen sank zudem die gesamte Speichernutzung
  • TypeScript 7.0 hat noch keine stabile Programmier-API, daher müssen Tools mit eingebettetem TypeScript wie typescript-eslint, Vue, MDX, Astro, Svelte oder die Typprüfung von Angular-Templates parallel mit TypeScript 6.0 betrieben werden
  • Wegen neuer Standardwerte und entfernter Optionen ist es für die Umstellung vorteilhaft, zunächst die Änderungen aus TypeScript 6.0 anzuwenden; eine neue API ist für TypeScript 7.1 vorgesehen

Natives TypeScript auf Go-Basis

  • TypeScript 7.0 ist ein nativer Port der TypeScript-Toolchain und nutzt eine neue, in Go geschriebene Codebasis
  • Die Portierung erfolgte mit dem Ziel, Struktur und Logik der bisherigen Codebasis so weit wie möglich beizubehalten, um Konsistenz der Ergebnisse und Kompatibilität zwischen beiden Compilern sicherzustellen
  • Die neue Codebasis liefert durch die Geschwindigkeit nativen Codes, Multi-Threading auf Shared-Memory-Basis und verschiedene Optimierungen bei vollständigen Builds typischerweise 8- bis 12-mal schnellere Ergebnisse
  • Die Installation ist wie bisher über npm möglich
npm install -D typescript
  • Nach der Installation steht im Workspace die neue ausführbare Datei tsc zur Verfügung und kann mit npx tsc ausgeführt werden

Kürzere Feedback-Schleifen in der Entwicklung

  • TypeScript ist an vielen Schritten des Entwicklungsprozesses beteiligt, darunter Editor-Start, Suche nach allen Referenzen, Autovervollständigung, Diagnosen, tsc und der Modus --watch
  • TypeScript 7 verkürzt die Wartezeiten in diesem gesamten Ablauf und macht die Feedback-Schleife kürzer
  • In der VS-Code-Codebasis sank die Zeit bis zur Anzeige des ersten Fehlers beim Öffnen einer fehlerhaften Datei von etwa 17,5 Sekunden auf unter 1,3 Sekunden und wurde damit mehr als 13-mal schneller
  • Die Editor-Unterstützung basiert auf LSP, und der neue Sprachserver verarbeitet durch Multi-Threading gleichzeitige Anfragen schneller
  • VS-Code-Nutzer können die dedizierte Erweiterung für TypeScript 7 installieren; in den kommenden Wochen soll die Unterstützung für TypeScript 7 auch direkt in VS Code selbst enthalten sein
  • Aktuelle Versionen von Visual Studio aktivieren TypeScript 7 je nach Workspace automatisch

Build-Performance und Speicherergebnisse

  • Der Vergleich der vollständigen Build-Zeiten von TypeScript 6 und 7 in großen Open-Source-Codebasen sieht wie folgt aus
Codebasis TypeScript 6 TypeScript 7 Beschleunigung
vscode 125.7 s 10.6 s 11.9x
sentry 139.8 s 15.7 s 8.9x
bluesky 24.3 s 2.8 s 8.7x
playwright 12.8 s 1.47 s 8.7x
tldraw 11.2 s 1.46 s 7.7x
  • Bei denselben Builds war bei TypeScript 7 in der Regel auch die gesamte Speichernutzung geringer
Codebasis TypeScript 6 TypeScript 7 Speicherveränderung
vscode 5.2GB 4.2GB -18%
sentry 4.9GB 4.6GB -6%
bluesky 1.8GB 1.3GB -26%
playwright 1.0GB 0.9GB -11%
tldraw 0.6GB 0.5GB -15%

Verifikation an realen Codebasen und Feedback von Teams

  • Das TypeScript-Projekt führt bei jedem Commit auf dem Branch main zehntausende Tests aus, die sich über mehr als zehn Jahre angesammelt haben
  • Zusätzlich zu diesen Tests wurde TypeScript 7 an realen Codebasen großer interner und externer Teams verifiziert
  • Innerhalb von Microsoft wurde TypeScript 7 von den Teams hinter Loop, Office, PowerBI, Teams und Xbox verifiziert
  • Extern testeten unter anderem Bloomberg, Canva, Figma, Google, Lattice, Linear, Miro, Notion, Sentry, Slack, Vanta, Vercel und VoidZero die neue Version in ihren Codebasen und gaben Feedback
  • Der neue Sprachserver reduziert gegenüber TypeScript 6.0 fehlgeschlagene Sprachserver-Befehle um mehr als 80 % und Server-Abstürze um mehr als 60 %
  • Zum Feedback aus realen Teams gehören unter anderem folgende Beispiele
    • Slack berichtet, dass sich mit TypeScript 7 die Zeit in der Merge Queue um 40 % verringerte und die CI-Typprüfung von etwa 7,5 Minuten auf 1,25 Minuten sank
    • Vanta erzielte in einem seiner großen Projekte eine bis zu 9-fache Beschleunigung der Builds
    • Das Team von Microsoft News Services spart monatlich 400 Stunden Wartezeit bei CI-Builds
    • Canva berichtet, dass die Zeit bis zur Anzeige des ersten Fehlers im Editor von etwa 58 Sekunden auf 4,8 Sekunden sank

Parallelbetrieb mit TypeScript 6.0

  • TypeScript 7.0 enthält noch keine API
  • Eine neue und andere API ist für TypeScript 7.1 geplant
  • Bis dahin können für Tools, die programmatischen Zugriff auf den Compiler benötigen, TypeScript 6.0 und 7.0 parallel betrieben werden
  • Das neue Kompatibilitätspaket @typescript/typescript6 stellt die ausführbare Datei tsc6 bereit und exportiert die TypeScript-6.0-API erneut
  • Für Tools wie typescript-eslint, die typescript als Peer Dependency direkt importieren, wird die Verwendung eines npm-Alias empfohlen
npm install -D typescript@npm:@typescript/typescript6
  • Um die TypeScript-6-API zusammen mit tsc aus TypeScript 7 zu verwenden, kann man wie folgt Aliase setzen
{
  "devDependencies": {
    "@typescript/native": "npm:typescript@^7.0.2",
    "typescript": "npm:@typescript/typescript6@^6.0.2"
  }
}
  • Das bisherige Paket @typescript/native-preview stellte Nightly-Builds der neuen TypeScript-7-Codebasis bereit und verzeichnete mehr als 8,5 Millionen Downloads pro Woche
  • Künftig sollen Nightly-Builds über das Tag next des Standardpakets typescript wieder aufgenommen werden
npm install -D typescript@next

Optionen zur Steuerung der Parallelisierung

  • TypeScript 7.0 führt mehrere Phasen wie Parsing, Typprüfung und Emit parallel aus

  • Parsing und Emit lassen sich leicht dateiweise unabhängig ausführen und skalieren daher in großen Codebasen mit vergleichsweise geringem Overhead

  • Die neuen experimentellen Flags --checkers, --builders und --singleThreaded steuern das Verhalten der Parallelisierung

  • --checkers

    • TypeScript 7.0 erstellt eine feste Anzahl von Worker-Prozessen für die Typprüfung und verteilt die Arbeit für dieselben Eingabedateien stets identisch, um dieselben Ergebnisse zu liefern
    • Standardmäßig gibt es 4 Worker für die Typprüfung; dies lässt sich mit --checkers anpassen
    • Die Ergebnisse auf derselben Maschine mit --checkers 8 sehen wie folgt aus
    Codebasis TypeScript 6 TypeScript 7 --checkers 8 Beschleunigung
    vscode 125.7 s 7.51 s 16.7x
    sentry 139.8 s 12.08 s 11.6x
    bluesky 24.3 s 2.01 s 12.1x
    playwright 12.8 s 1.16 s 11x
    tldraw 11.2 s 1.06 s 10.6x

  • Durch Erhöhen von --checkers können mehr CPU-Kerne genutzt werden, was Builds beschleunigen kann, in der Regel aber mit höherem Speicherverbrauch einhergeht

    • Auf CI-Runnern mit wenigen CPU-Kernen und wenig Arbeitsspeicher kann ein niedrigerer Wert unnötigen Overhead vermeiden
    • --checkers 1 macht die Typprüfung praktisch single-threaded und eliminiert doppelte Arbeit
    • In seltenen Fällen können Änderungen an der Anzahl von --checkers reihenfolgeabhängige Ergebnisse sichtbar machen; daher kann es hilfreich sein, in der gesamten Build-Umgebung eine feste Zahl von Checkern vorzugeben

  • --builders

    • --builders steuert bei der Ausführung von --build die Anzahl der Projekt-Referenz-Builder, die gleichzeitig laufen können
    • Das kann besonders in Monorepos mit vielen Projekten hilfreich sein
    • Ein höherer Wert kann Builds beschleunigen, aber auch den Speicherverbrauch erhöhen
    • Es gibt einen Multiplikationseffekt mit --checkers: Bei --checkers 4 --builders 4 können maximal 16 Typprüfer gleichzeitig laufen
    • Anders als bei --checkers sollten Änderungen an der Zahl von --builders nicht zu anderen Ergebnissen führen
    • Builds mit Projekt-Referenzen werden grundsätzlich durch den Abhängigkeitsgraphen der Projekte begrenzt

  • --singleThreaded

    • --singleThreaded lässt den gesamten Compiler in einem einzigen Thread laufen
    • Das kann für Debugging, Leistungsverg­leiche zwischen TypeScript 6 und 7, externe Orchestrierung paralleler Builds und Umgebungen mit sehr stark begrenzten Ressourcen nützlich sein
    • Dieses Flag begrenzt nicht nur die Zahl der Worker für die Typprüfung auf 1, sondern führt auch Parsing und Emit in einem einzigen Thread aus

Neuer --watch-Modus

  • TypeScript 7 hat den --watch-Modus vollständig neu aufgebaut
  • Das neue --watch bietet auf Basis des File-Watchers des Parcel-Bundlers eine effiziente und stabile plattformübergreifende Dateiüberwachung
  • Die Go-Standardbibliothek enthält keine eingebaute API zur Dateiüberwachung, und die geprüften Drittanbieter-Bibliotheken hatten Probleme bei Stabilität, Performance, plattformübergreifender Unterstützung und der Integration in Build-Tools
  • Ein reines Polling-Verfahren funktionierte zwar auf verschiedenen Betriebssystemen, war bei großen Projekten mit vielen node_modules-Abhängigkeiten jedoch rechenintensiv
  • Das TypeScript-Team hat @parcel/watcher, das bereits in VS Code verwendet wird, nach Go portiert und minimale Assembly-Shims eingesetzt, um Abhängigkeiten von C++-Toolchains zu vermeiden
  • Dieser Watcher ist ein eigenständiges Paket und verbessert im --watch-Modus von TypeScript 7 den Ressourcenverbrauch plattformübergreifend

Änderungen bei Standardwerten und Kompatibilität in TypeScript 6.0

  • TypeScript 7.0 wurde so entwickelt, dass es mit dem Verhalten der Typprüfung und der Kommandozeile von TypeScript 6.0 kompatibel ist
  • Code, der sich unter TypeScript 6.0 mit aktiviertem stableTypeOrdering und ohne gesetztes ignoreDeprecations sauber kompilieren lässt, sollte sich auch unter TypeScript 7.0 unverändert kompilieren lassen
  • TypeScript 7.0 übernimmt die neuen Standardwerte von TypeScript 6.0 und erzeugt für in TypeScript 6.0 als deprecated markierte Flags und Syntaxformen einen hard error
  • Die wichtigsten Änderungen bei den Standardwerten sind:
    • strict ist standardmäßig true
    • module ist standardmäßig esnext
    • target ist standardmäßig die aktuelle stabile ECMAScript-Version direkt vor esnext
    • noUncheckedSideEffectImports ist standardmäßig true
    • libReplacement ist standardmäßig false
    • stableTypeOrdering ist standardmäßig true und kann nicht deaktiviert werden
    • rootDir ist standardmäßig ./
    • types ist standardmäßig []; das frühere Verhalten lässt sich mit ["*"] wiederherstellen
  • Als die überraschendsten Änderungen gelten wahrscheinlich rootDir und types
    • Projekte, bei denen sich die tsconfig.json außerhalb eines Quellverzeichnisses wie src befindet, müssen rootDir explizit angeben, um die bestehende Verzeichnisstruktur beizubehalten
    • Projekte, die auf bestimmte globale Deklarationen angewiesen sind, müssen die benötigten @types-Pakete in types explizit angeben
{
  "compilerOptions": {
    "rootDir": "./src"
  },
  "include": ["./src"]
}

{
  "compilerOptions": {
    "types": ["node", "jest"]
  }
}

Entfernte Verhaltensweisen oder solche, die zu hard errors geworden sind

  • In TypeScript 7.0 werden mehrere Optionen und Syntaxformen, die in TypeScript 6.0 als deprecated markiert wurden, nicht mehr unterstützt
  • Zu den wichtigsten Punkten gehören:
    • target: es5 wird nicht unterstützt
    • downlevelIteration wird nicht unterstützt
    • moduleResolution: node/node10 wird nicht unterstützt, empfohlen werden nodenext und bundler
    • module: amd, umd, systemjs, none wird nicht unterstützt; empfohlen werden esnext oder preserve zusammen mit bundler- oder browserbasierter Modulauflösung
    • baseUrl wird nicht unterstützt; paths kann aktualisiert werden, sodass statt baseUrl relative Pfade vom Projekt-Root aus verwendet werden
    • moduleResolution: classic wird nicht unterstützt, empfohlen werden bundler oder nodenext
    • esModuleInterop und allowSyntheticDefaultImports können nicht auf false gesetzt werden
    • alwaysStrict gilt als true und kann nicht auf false gesetzt werden
    • Das Schlüsselwort module kann in Namespace-Deklarationen nicht verwendet werden
    • Das Schlüsselwort asserts kann in Imports nicht verwendet werden; entsprechend den Änderungen der ECMAScript-Syntax für Import-Attribute muss with verwendet werden
    • Unter skipDefaultLibCheck wird die Direktive /// <reference no-default-lib /> nicht mehr berücksichtigt
    • Wenn im aktuellen Verzeichnis eine tsconfig.json vorhanden ist, können Kommandozeilen-Builds keine Dateipfade annehmen; dafür ist ein explizites --ignoreConfig erforderlich

Änderungen bei Template-Literal-Typen und der JavaScript-Unterstützung

  • TypeScript 7.0 behandelt Unicode-Codepoints bei der Inferenz von Template-Literal-Typen auf natürlichere Weise
type HeadTail<S> = S extends `${infer Head}${infer Tail}` ? [Head, Tail] : never;

type Result = HeadTail<"😀abc">;
// 7.0: ["😀", "abc"]
// früher: ["\ud83d", "\ude00abc"]
  • Bisher wurde "😀" entsprechend dem UTF-16-Indexing-Verhalten von JavaScript in die beiden Teile eines Surrogate-Paars aufgespalten
  • Das neue Verhalten entspricht eher der Intuition von for...of oder [...str], die "😀" als eine einzige Einheit behandeln
  • Für String-Manipulationen auf Typebene, die bewusst UTF-16-Code-Units modellieren, kann das eine breaking change sein
  • Die JavaScript-Unterstützung wurde überarbeitet, damit sie konsistenter mit der Analyseweise von TypeScript-Dateien ist
    • Werte können an Typ-Positionen nicht verwendet werden; stattdessen muss typeof someValue genutzt werden
    • @enum wird nicht mehr speziell behandelt
    • Ein eigenständiges ? kann nicht als Typ verwendet werden; stattdessen muss any verwendet werden
    • @class macht aus einer Funktion keinen Konstruktor; es muss eine class-Deklaration verwendet werden
    • Postfix-! wird nicht unterstützt
    • Typnamen müssen innerhalb eines @typedef-Tags definiert werden
    • Die Closure-ähnliche Funktionssyntax wird nicht mehr unterstützt; stattdessen muss die verkürzte TypeScript-Syntax verwendet werden
  • Auch einige JavaScript-Muster wie this-Aliasing und die vollständige Neuzuweisung von Funktions-prototype werden nicht mehr speziell behandelt
  • Die Unterschiede zwischen TypeScript 6.0 und 7.0 sind ausführlicher in CHANGES.md dokumentiert

Editorfunktionen und Einschränkungen

  • TypeScript 7.0 ergänzt mehrere Editorfunktionen, die seit der Beta noch gefehlt hatten
  • Enthalten sind Auto-Import, erweiterbare Hover-Informationen, Inlay Hints, Code Lens, Go-to-Source-Definition, JSX Linked Editing und Tag Completion
  • Auch Funktionen, die in der TypeScript-7.0-Beta fehlten, wie Semantic Highlighting, „sort imports“ und „remove unused imports“, sind enthalten
  • Für die Qualität des Language Servers wurden Test- und Diagnoseinfrastruktur neu aufgebaut, und es können Fuzz-Tests gegen wichtige TypeScript- und JavaScript-Codebasen auf GitHub durchgeführt werden

Aktuelle Einschränkungen integrierter Sprach-Workflows

  • Workflows mit Vue, MDX, Astro, Svelte und ähnlichen Technologien können TypeScript 7 vermutlich noch nicht nutzen
  • Auch spezielle Template-Typprüfungen wie Angular-Templates können TypeScript 7 voraussichtlich nicht verwenden
  • Der Hauptgrund ist, dass TypeScript 7 noch keine stabile Programmier-API bereitstellt
  • Tools wie Volar, die TypeScript in ihren eigenen Compiler und Sprachdienst einbetten, müssen derzeit zwangsläufig von TypeScript 6.0 abhängen
  • Das TypeScript-Team betrachtet dies als eine zeitlich begrenzte Einschränkung und plant, gemeinsam mit den Maintainers der betreffenden Projekte Unterstützung für TypeScript 7 sicherzustellen
  • Bis dahin wird empfohlen, TypeScript 7 in Szenarien zu verwenden, die kein Language-Server-Plugin benötigen
  • Angular-Projekte können in der CLI tsc aus TypeScript 7 für eine schnelle projektweite Fehlererkennung nutzen und für Editor-Support parallel TypeScript 6.0 verwenden
  • Vue, MDX, Astro, Svelte und ähnliche Technologien müssen vorerst weiterhin TypeScript 6.0 verwenden
  • In VS Code kann mit dem Befehl „Disable TypeScript 7 Language Server“ wieder auf TypeScript 6.0 zurückgewechselt werden

Ausblick

  • Die Veröffentlichung von TypeScript 7.0 ist ein wichtiger Meilenstein des nativen Ports, an dem im TypeScript-Projekt mehr als ein Jahr lang schwerpunktmäßig gearbeitet wurde
  • Nach 7.0 soll die Arbeit wieder auf neue Funktionen, Verbesserungen der Nutzbarkeit, zusätzliche Performance-Optimierungen und die Implementierung neuer APIs für das Ökosystem zurückkehren
  • Ähnlich wie vor TypeScript 7.0 wird voraussichtlich alle 3–4 Monate eine neue Funktionsversion erscheinen
  • Für TypeScript 7.1 sind das Schließen von Lücken zur Unterstützung der Community-Migration sowie neue APIs vorgesehen

Verwandte Beiträge

2 Kommentare

 
GN⁺ 2 시간 전
Hacker-News-Kommentare

  • Laut den eigenen Benchmarks sehen die Geschwindigkeitsgewinne von TypeScript 7 so aus

    Codebase TypeScript 6 TypeScript 7 Speedup
    vscode 125.7s 10.6s 11.9x
    sentry 139.8s 15.7s 8.9x
    bluesky 24.3s 2.8s 8.7x
    playwright 12.8s 1.47s 8.7x
    tldraw 11.2s 1.46s 7.7x

    Das Team ist beeindruckend, wenn es bei einer verantwortungsvollen Migration solche Ergebnisse erzielt hat. Bun könnte sich daran ruhig ein Beispiel nehmen. Ich frage mich, welche Auswirkungen das auf nachgelagerte Tools hat, die TypeScript-Codebasen bauen müssen, wie tsdown oder esbuild, und ob man TS 7 zusammen mit dem aktuellen tsdown verwenden kann

    • esbuild hängt überhaupt nicht von TypeScript ab, also gibt es dort kein Problem. Bei tsdown hängt es davon ab, ob --isolatedDeclarations verwendet wird; wenn nicht, kann man wie im Blog beschrieben TypeScript 6 parallel installieren
    • Würdest du also sagen, dass Buns Migration unverantwortlich war?

  • Früher wurde ja sogar darüber gestritten, ob Typen den Aufwand überhaupt wert sind. Das Gute an TypeScript ist vor allem, dass es Typen massentauglich gemacht hat

    • Ich kann mich nicht gut daran erinnern, dass Leute Typen an sich gehasst hätten. Was viele nicht mochten, war statische Typisierung, genauer gesagt statische und explizite Typisierung.
      Ich habe zum Beispiel mehrfach gehört, Python sei unbenutzbar, weil es keine Typen habe, was unsinnig ist. Python ist eine stark typisierte Sprache und zugleich dynamisch typisiert.
      Es gibt tatsächlich Sprachen ohne echte Typen oder mit dem, was man oft „stringly typed“ nennt. AREXX, mit dem ich als Kind herumgespielt habe, behandelte jeden Wert als String, auch wenn er wie eine Zahl aussah, und viele Unix-CLI-Tools wie sed kann man ähnlich sehen. Die meisten Typ-Debatten drehten sich aber um dynamisch typisierte Sprachen wie Python, und ich habe kaum jemanden erlebt, der behauptete, schwach typisierte oder untypisierte Sprachen seien gut für große Projekte. Stattdessen habe ich oft gehört, Python habe „keine Typen“ und tauge deshalb nicht für große Projekte, was aus der Sicht von jemandem, der tatsächlich große Projekte in Python gebaut hat, verwirrend war
    • Die Typsysteme früher waren einfach nicht besonders gut. Für „OR“-Typen wie Summentypen in Klassenhierarchien gezwungen zu werden, ist unerquicklich. Moderne Sprachen mit Summentypen wie TypeScript, Rust, Swift und Kotlin sind deutlich angenehmer
    • Ich habe persönlich dreimal mit Leuten gesprochen, die fast wortwörtlich meinten, sie hätten in JavaScript noch nie Typing-Fehler erlebt. Zwei davon waren Leute, deren Arbeit ich respektierte, deshalb fiel es mir schwer zu verstehen, wie man so eine Haltung haben kann
    • Algebraische Datentypen und Pattern Matching haben alles verändert. Es muss gar nicht so extrem sein wie Haskell, und plötzlich werden Typen viel nützlicher.
      Früher war ich Typsystemen meist über C++ und Java ausgesetzt, und gerade C++ taugt kaum als positives Beispiel für irgendetwas außer dafür, wie man eine überkomplexe Sprache baut. Wenn man einmal gesehen hat, wie gut eingesetzte Typen aussehen, lassen sie sich viel leichter vermitteln
    • Jetzt warte ich nur noch auf DependentTypeScript

  • Wirklich beeindruckend ist hier das großartige Team, das parallel zwei separate Codebasen für das fortschrittlichste Typsystem gepflegt hat, das die Menschheit kennt. Ich freue mich auch auf den Rust-Rewrite

    • Ich bin nicht sicher, ob ein Rust-Rewrite viel bringen würde. Mit Go kann man schnell entwickeln, und es ist wohl relativ einfach, TypeScript beim Lesen des Codes 1:1 nachzubauen.
      Mit Rust würde die Entwicklung viel länger dauern. Vielleicht ist Rust 20 % schneller als Go, aber schon der Gewinn von TypeScript zu Go ist gewaltig. Bei vscode könnten es mit Rust vielleicht 14x statt 11x mit Go sein, aber Go allein reicht schon völlig aus, um einen enormen Unterschied zu machen
    • Ich weiß nicht, ob es zwar das komplexeste, aber wirklich das „fortschrittlichste“ Typsystem ist. Darauf gibt es wohl keine eindeutige Antwort, aber eine Sprache aus dem Bereich der Proof Assistants wäre vielleicht ein plausiblerer Kandidat.
      Das soll TypeScripts Typsystem nicht kleinreden; es ist wirklich sehr spannende Arbeit
    • Steve Francia, der Hugo und mehrere große Go-Projekte gebaut hat, hat über Go im Zeitalter der Agenten geschrieben: https://spf13.com/p/go-the-agentic-language/
    • Ich frage mich, was mit „dem fortschrittlichsten Typsystem, das die Menschheit kennt“ genau gemeint ist
    • Soweit ich weiß, wurden Rust und andere Optionen ernsthaft geprüft und dann Go gewählt. Ich erinnere mich nicht mehr an alle Gründe, aber im ursprünglichen Blogpost wurde das ausführlich erklärt

  • Nach ein paar Jahren mit TypeScript fühlt es sich in Python wirklich umständlich an, Typannotationen von Hand zu ergänzen und grundlegende Sprachfeatures wie abc dazuzuholen

  • Interessant, aber inzwischen entfernt Node TypeScript-Typannotationen nativ, deshalb starte ich TSC fast nie. Eigentlich nur noch dann, wenn ich eine große Regression verursache und per statischer Compiler-Ausgabe prüfen muss, was ich nicht aktualisiert habe.
    Auch Frontend-Code, der im Browser landen soll, verlässt sich auf die Typentfernung von Node

    • Stimmt, aber andererseits läuft im Editor den ganzen Tag der TypeScript Language Server. In CI wahrscheinlich ebenfalls, und AI-Agenten vermutlich auch, bevor sie Vertrauen in das haben, was sie gerade geändert haben

  • Es freut mich, dass die JSDoc-Typensyntax weiter Aufmerksamkeit bekommt. Für private Projekte ist das meine liebste Art, TypeScript zu verwenden. Einige Syntaxänderungen werden beim Aktualisieren lästig sein, aber größtenteils scheint es eine Verbesserung zu sein

  • Ein großer Schmerzpunkt bei TypeScript ist, dass sich der Geltungsbereich von tsconfig-Einstellungen wie lib und types für Teile eines Projekts nur schwer anpassen lässt.
    Das Projekt ist eine Web-App, aber wegen vite.config.ts, Playwright und Unit-Tests geraten auf der IDE-Seite Node-Typen hinein. Selbst wenn man einer React-Komponente eine Node-API hinzufügt, beschwert sich tsc nicht.
    Um derzeit DOM-Bibliotheken und Node-Bibliotheken zu isolieren, braucht man ein Spaghetti-Konstrukt aus Projektverweisen, unzähligen tsconfig.json- und tsbuildinfo-Ausgabedateien, und es ist umständlich, mit Projektverweisen Typsausgaben zu vermeiden.

    • Ich stimme zu, das ist wirklich schmerzhaft. Ich nutze nx, das einem solche Dinge abnimmt. Playwright ist ein separates Projekt mit eigener tsconfig, und alles erbt von der Root-tsconfig.
      Ich bevorzuge nx sogar bei einer einzelnen Anwendung und verschiebe gemeinsamen Code in „Bibliotheken“. Ich verwende Bibliotheken, die nicht gebaut werden, und das ist bei größeren Projekten ziemlich gut.

  • Es gibt noch keine TypeScript-Compiler-API, aber da daran gearbeitet wird, freue ich mich darauf.

    • Soll in 7.1 kommen.

  • Wenn man die Grafiken sieht, in denen der Speicherverbrauch sinkt und die Performance stark steigt, kommt einem der Gedanke, dass man serverseitig vielleicht lieber Go statt TypeScript verwenden sollte.

    • Zunächst einmal führt man serverseitig nicht TypeScript aus. Unabhängig von der Runtime-Engine läuft der transformierte Code oder JavaScript.
      Und ich verstehe ehrlich gesagt nicht so recht, warum heute noch jemand neue Projekte mit TS/JS/Python startet, obwohl es inzwischen Alternativen gibt.
    • Es könnte daran liegen, dass man mit Frontend-Projekten Typen oder Module teilen kann. Bei Anwendungen, die nicht CPU-intensiv sind, macht es vielleicht kaum einen Unterschied, oder man ist einfach damit vertraut und arbeitet gern damit. Dazu kommt, dass das Bibliotheks-Ökosystem riesig ist.
    • Das ist Build-Zeit-Performance, nicht Laufzeit-Performance.
    • Ob der Performance-Unterschied zwischen Go und JS (Node usw.) wichtig ist, hängt vom Anwendungsfall ab. Für den TypeScript-Compiler ist er sicher wichtig, für eine CRUD-App möglicherweise überhaupt nicht.
    • Wenn möglich, ist es einfach leichter, mit einer einzigen Hauptsprache zu arbeiten.

  • Glückwunsch an das TypeScript-Team. Ich hätte viel dazu zu schreiben oder als Audio aufzunehmen, aber kurz gesagt ist das JavaScript/TypeScript-Ökosystem wie das Arbeiten mit Holz.
    Man kann billige laminierte Pressholzplatten und Ikea-artige Dinge bauen. In Code wären das wohl einfallslose Vibecoding-Apps.
    Andererseits sind auch hochwertige handgefertigte Möbel oder mehrstöckige Holzbauten möglich. Etwa indem man junges Holz verwendet und mit maßgeschneiderten Verbindungen und Laminierungstechniken feuerbeständige Träger herstellt. Auch im JavaScript/TypeScript-Ökosystem können hochwertige Ergebnisse entstehen, wenn man KI wie eine leistungsfähige Werkzeugmaschine nutzt und dabei handwerklichen Anspruch bewahrt. Wenn man den Mut hat, etwas zu bauen und auszuführen, kann man das TypeScript/JavaScript-Ökosystem annehmen.
 
GN⁺ 2 시간 전
Meinungen auf Lobste.rs

  • Ich verstehe den Grund, aber es ist interessant, dass man von einem self-hosting Compiler zu einem nicht self-hosting Compiler gewechselt ist.
    Normalerweise geht es fast immer in die entgegengesetzte Richtung, daher ist das ein ungewöhnlicher Verlauf.

    • Ich denke, wir sollten diese Richtung häufiger sehen. Nicht jede Sprache eignet sich zum Schreiben von Compilern.
      Self-Hosting erzeugt einen starken Druck, dass sich die Sprache zu einer Sprache entwickelt, in der man Compiler besser schreiben kann, aber das ist vielleicht nicht immer die richtige Richtung.
    • Überraschend, dass Sprachdesigner und Implementierer verstehen, dass ihre eigene Sprache nicht für jeden Zweck perfekt ist.

  • Auch wenn man nicht in TypeScript programmiert: VSCode selbst ist in TypeScript geschrieben, daher frage ich mich, ob diese Verbesserung auch Auswirkungen auf die Geschwindigkeit von VSCode hat.
    Oder ob sie nur die TypeScript-Spracherweiterung betrifft.

    • Der Compiler wird schneller; er erzeugt nicht auf magische Weise schnelleren Code.
    • Das betrifft nur die TypeScript-Spracherweiterung.
    • TypeScript wird zu JavaScript kompiliert. Wenn VSCode läuft, führen node.js und Chromium JavaScript-Code aus.
      Schneller wird hier nur der Compiler, der TypeScript-Code nimmt und in JavaScript umwandelt; dieser Prozess findet in der Build-Pipeline statt, bevor Microsoft die VSCode-Executable ausliefert.
      Eine mögliche Ausnahme wäre, dass auch der TypeScript-LSP-Server schneller werden könnte, weil er zur Laufzeit tatsächlich TypeScript-Code parst. Das ist allerdings unabhängig davon, dass VSCode in TypeScript geschrieben ist.
    • Der TypeScript-Compiler macht tatsächlich gar nicht so viel. Bei tsc gibt es einiges, das als WONTFIX markiert wird, weil das Prinzip gilt, dass der gerade verarbeitete Code abgesehen von minimalen Dingen wie dem Entfernen von Typen nicht angefasst werden soll.
      Deshalb erwarte ich, dass sich die Performance-Eigenschaften von Tools, die mit TypeScript gebaut wurden, kaum ändern werden.

  • Ein kleiner persönlicher Tipp: Das Projekt, an dem ich gerade arbeite, verwendet TS 5, aber wie erwartet wollte ich das in nvim nicht verwenden.
    Also habe ich zuerst TS 7 mit mise installiert und in node_modules/.bin einen symbolischen Link tsgo erstellt, der auf das mit mise installierte TS zeigt.
    Da nvim-lspconfig immer noch den alten Dateinamen tsgo aus der Zeit der technischen Preview verwendet, führt nvim statt des lokalen TS das installierte TS 7 aus.