<p>TypeScript 4.0-Iterationsplan</p>

Würden Sie in Betracht ziehen, https://github.com/microsoft/TypeScript/pull/29818 in 4.0 einzufügen, vielleicht hinter dem experimentellen Flag?

Das wird durch die Änderung der Werksfunktionsdefinition an sich kompliziert.

Es könnte jedoch interessant sein, eine _separate_ virtuelle Fabriktypdefinition einzuführen; sagen wir JSX.Factory oder React.JSX.Factory , die TypeScript dann für Rückschlüsse verwenden könnte. Ich bin mir nicht ganz sicher, ob das bloße Übersetzen der JSX-Grammatik in Funktionsaufrufe ausreichend oder effizient ist, aber da es sich um einen virtuellen Typ handelt, muss er keiner konkreten JavaScript-Entität entsprechen. Das Risiko besteht natürlich darin, in die gleiche Situation zu geraten wie jetzt, mit einer Reihe virtueller Typen, die letztendlich die Typsicherheit nicht nur von Kindern, sondern auch von mehreren nach React 15 eingeführten Funktionen einschränken.

Würden Sie in Erwägung ziehen, auch https://github.com/microsoft/TypeScript/pull/24738 in 4.0 aufzunehmen?

Ich bin ein bisschen traurig, dass Nr. 33038 [👍 140 und eine tatsächliche PR von Ihrem eigenen @weswigham] oder Nr. 202 [👍 390] nicht erwähnt werden, während Tickets wie Nr. 15230 [👍 27] als "stark nachgefragt" gelten. Mir ist klar, dass Sie auf der Grundlage von „Gefällt mir“ nicht wirklich vergleichen oder priorisieren können, aber es wäre großartig, wenn es dazu ein Roadmap-Update geben würde, zumal 4.0 eine gute Gelegenheit zu sein scheint, ein Feature wie dieses einzuführen. 🙏

~ 3,5 Jahre altes Problem wartet auf Feedback mit fast 200 Kommentaren # 13778 mit ungenauen Eingaben für Dinge wie Array-Destrukturierung. Pwetty pwease können wir eine Lösung implementieren 🙏

Ich weiß es zu schätzen, dass Leute gelegentlich Probleme hervorheben, von denen sie glauben, dass sie in den Roadmaps und Iterationsplänen beachtet werden müssen, aber ich denke, ich muss hier klarstellen, dass der Abschnitt „Fehlerbehebungen mit hoher Nachfrage untersuchen“ bestimmt wurde, indem Probleme durchgesehen wurden, die eindeutig eine Menge verursacht haben Scherenschnitte, die aber im Umfang vernünftig erschienen. Wir sind uns der erwähnten Probleme definitiv immer noch bewusst, aber einige von ihnen sind nicht so umfassend und haben kein klares ideales Ergebnis.

Beispiele:

• Nominelle Marken wären schön, aber würde das mit der zukünftigen Sprachrichtung rund um Nominalität komponieren? Ich habe sogar diese Bedenken mit Platzhaltertypen als die Person, die es vorgeschlagen hat.
• undefined auf Index-Signaturen ist ein interessantes Beispiel, aber wir wollen kein Verhalten hinzufügen, das es 90 % der Menschen erschwert, die bereits mit den aktuellen Annahmen arbeiten. Einen Ansatz zu finden, der diese Überprüfungen zusammenstellt und es den Benutzern ermöglicht, diese Prüfungen schrittweise zu übernehmen, ist für uns nicht selbstverständlich. Auch wenn es mit einer Reihe von bedingten Typen und speziellen Compiler-Prüfungen technisch möglich ist, neigen diese Lösungen dazu, sehr eindeutig hackig zu sein und schnell zusammenzubrechen.

Nominelle Marken wären schön, aber würde das mit der zukünftigen Sprachrichtung rund um Nominalität komponieren?

@DanielRosenwasser , was ist die zukünftige Sprachrichtung deiner Vision?

Ich schätze, ich werde etwas Kontext geben, wo meine Meinung zu Nominalität ist. Es gibt viele verschiedene Ideen, die Menschen im Kopf haben, wenn sie nach nominalen Typen fragen, einschließlich

• "Traditionelle" deklarationsbasierte Nominalität (z. B. was Sie in den meisten OO-Sprachen sehen)
• Undurchsichtige Typen (Typen, deren Inhalt außerhalb völlig unbekannt ist)
• Eindeutige Aliase (einzelne struct s in C/C++/C#, newtype in Haskell, Inline-Klassen in Kotlin)
• Maßeinheiten (eine Möglichkeit, dimensionale Analysen in die Sprache zu kodieren)

Zwischen einigen davon gibt es Schattierungen (z. B. Platzhaltertypdeklarationen - eine Art Variante von undurchsichtigen Typen, die auf einen Implementierungstyp zurückgreifen), und dann gibt es verschiedene Richtungen, die diese miteinander verschmelzen.

@RyanCavanaugh hatte eine großartige Analogie dazu, wo 3 Kinder ihre Eltern um ein Haustier bitten. Man will einen Hund, man will eine Katze, man will einen Fisch. Sie fragen ihre Eltern "wann bekommen wir ein Haustier!?" Offensichtlich sind sich alle einig, dass sie ein Haustier wollen, aber jeder will ein anderes Haustier!

Mag ich Markentypen? Ich mache! Markentypen erzielen so etwas wie eindeutige Aliase und erfüllen die Anforderungen, die die meisten Benutzer suchen. Aber ich glaube nicht, dass das der richtige Weg ist, darüber nachzudenken. Es gibt mehr Designraum, der mit vielen bekannten Kompromissen ausgestaltet werden muss, und nichts gibt mir das Gefühl, dass wir so schnell wie möglich eine Lösung finden müssen.

Ich würde gerne, wenn wir https://github.com/microsoft/TSJS-lib-generator/pull/858 in TypeScript 4.0 bekommen könnten.

@DanielRosenwasser erstmal danke für die Zuschrift 🙇

Können Sie ein wenig erläutern, welche Anwendungsfälle nominale Typen tatsächlich für TypeScript ansprechen?

Erstens: Fühlen Sie sich frei, mich zu einer riesigen Textwand oder einem Repo zu schicken, und ich werde es lesen :]

Ich meine nicht undurchsichtige Typen wie Platzhaltertypen - ich meine das, was Sie "traditionelle" nominale Typen nennen.

Ich hatte immer das Gefühl, dass nominale Typen im Gegensatz zu JavaScript stehen, und deshalb haben frühere Versuche nicht so gut funktioniert. Es gibt Möglichkeiten, es ziemlich gut zum Laufen zu bringen (Protokolle in Swift und Typklassen in Haskell fallen mir ein als "Nominal, aber von außen erweiterbar"), und ich bin sicher, Sie sind mit den meisten der "gut etablierten" Methoden vertraut (I davon aus, dass „Maßeinheiten“ ein F#-Zwinker ist).

Ich habe viele Leute gefunden, die nach nominellen (wie in "traditionellen") Typen fragen, aber nicht viele Zuschreibungen über _warum_.

Im Laufe der Zeit haben wir gesehen, dass immer weniger Leute nach „traditionellen“ nominellen Typen fragen, vielleicht weil die Community kollektiv einen mentalen Modus für strukturelle Typen entwickelt hat. Es gibt einige Stellen, an denen Typen wirklich nominell handeln (wenn es um instanceof geht oder wenn es um Private geht). Einiges davon wird durch bessere Kontrollflussanalysen und Kompatibilitätsprüfungen erfasst, aber es ist nicht perfekt.

Einige der "traditionellen" Anwendungsfälle sind die gleichen wie die eines nominellen Wrapper-Typs ohne Overhead (z. B. newtype ), und die meiste Zeit besteht die Absicht darin, eine spezielle Behandlung für Dinge wie Dateien sicherzustellen Pfade, nicht vertrauenswürdige Zeichenfolgen usw.

Ich habe das Gefühl, dass Typescript bereits ausdrucksstark genug ist. Was ich mir persönlich wünschen würde, ist eine bessere Tooling-Integration.

• Unterstützung für ESM https://github.com/microsoft/TypeScript/pull/35148 https://github.com/microsoft/TypeScript/issues/16577
• Compiler-Plugins https://github.com/microsoft/TypeScript/issues/16607 https://github.com/microsoft/TypeScript/issues/38736
• Garn pnp https://github.com/microsoft/TypeScript/issues/28289 https://github.com/microsoft/TypeScript/pull/35206

Aus den oben genannten Gründen ist es üblich, klobige und hackige Lösungen zu sehen. Die meisten React-Projekte haben babel für den React-Hot-Loader (Compiler-Plugins) enthalten, einige CSS-Systeme benötigen auch babel für Transformationen zur Kompilierzeit. Die Verwendung von pnp-, esm- oder sogar CSS-Modulen erfordert mehr Tools und Problemumgehungen für tsc-Einschränkungen.

Es ist auch frustrierend, dass die Community für einige dieser Probleme konkrete Lösungen in Form von PRs oder Vorschlägen vorgelegt hat, diese jedoch abgelehnt oder jahrelang blockiert wurden. Als Praktiker wird es immer schwieriger, TS im Kontext eines breiteren Ökosystems zu verwenden.

Wie auch immer, ich bin nur eine zufällige Person aus dem Internet.

@DanielRosenwasser könnte vielleicht https://github.com/microsoft/TypeScript/pull/29374 rechtzeitig für 4.0 überprüft werden? Ich denke, es deckt viele (die meisten?) der this -vor- super Fälle ab, nach denen die Leute fragen.

Bitte überdenken Sie die Einbeziehung der Unterstützung für die Referenzierung von ES-Modulen mit einem Dateipfad, der die Dateierweiterung enthält. Es wird einen großen Schub geben, um die Wettbewerbsbedingungen von Code für mehrere Umgebungen anzugleichen.

https://github.com/microsoft/TypeScript/issues/16577

Vielen Dank für Ihren Fokus auf die Werkzeuge rund um Typoskript! Ich hatte gehofft, Sie könnten eine engere Integration mit https://github.com/microsoft/tsdoc in Betracht ziehen. Viele andere moderne Sprachen wie go und rust bieten Dokumentationstools direkt nach dem Auspacken und ermutigen Entwickler, Standardkommentare zu schreiben, aber in dieser Hinsicht fehlt Typoskript.

Es wäre super toll, wenn #31445 abgeholt werden könnte, das war ein Deal Breaker für uns und ich glaube, viele Leute (basierend auf wie viele Referenzen diese Ausgabe hat)!

Kann https://github.com/microsoft/TypeScript/pull/38967 in TypeScript 4.0 aufgenommen werden, und vielleicht auch https://github.com/microsoft/TypeScript/pull/35608 .

Ich habe festgestellt, dass die Leute verlangen, dass alles in die Version 4.0 aufgenommen wird 😆

Fühlt es sich an, als würde TS an Schwung verlieren? Koaleszierende und kurzschließende Zuweisungen für die nächste _große_ Version 4.0.0 aufheben? Keine großen Ziele und ambitionierten Ideen mehr?

Für das nächste Major würde ich erwarten:

• Höherwertige Typisierung
• Abhängiges Tippen? Funktionen auf Typebene? (Ok, das kann für 5.0.0 sein)
• Nominale Typisierung
• Makrosen
• Unterstützung für Transformatoren in tsconfig.json
• Kompilierung zu WASM (von einigen Sprachuntergruppen)

@canonic-epicure Stimme zu, derzeit fühlt es sich eher wie eine 3.10 für die nächste Version an

Fühlt es sich an, als würde TS an Schwung verlieren? Nullish-Koaleszenz- und Kurzschluss-Zuweisungen für die nächste große Version 4.0.0? Keine großen Ziele und ambitionierten Ideen mehr?

TypeScript folgt nicht dem Semver. Es gibt nicht v0.10, v1.10, v2.10 oder v3.10. Das ist also eigentlich ein normaler Meilenstein. Es ist ein bisschen seltsam, dass die Leute so viele Änderungen in 4.0 erwarten, aber nichts in 3.9 oder früheren Iterationsplänen sagen. 🙈

Funktionen auf Typebene

type X<T> = T kann es auf einer gewissen Ebene tun. (unterstützt keine Funktionen höherer Ordnung.)

Makrosen

IMO erfüllt es nicht das Ziel des Typoskripts.

Unterstützung für Transformer in tsconfig.json

Probieren Sie es aus: https://github.com/cevek/ttypescript

Kompilierung zu WASM (von einigen Sprachuntergruppen)

Suchen Sie nach https://www.assemblyscript.org/

Ok, 4.0.0 ist also nur eine nächste Nebenversion, gut zu wissen.

In Bezug auf "Makrosen erfüllen nicht das TS-Ziel" und "verwende ttypescript für Transformatoren" ( ts-patch funktioniert übrigens besser) - dies ähnelt dem Jedi-Zug - "dies ist nicht die Funktion, die Sie brauchen". Nein, bitte Makros und Transformer out of the box. Es wurde vor Jahren angefordert.

Ich möchte auch marco in TypeScript, aber es gibt wirklich viele Gründe dagegen.

1. Wenn Marco anderen JavaScript-Code generieren kann, erstellt er eine neue Syntax auf Nichttypebene, daher ist es eine Erweiterung der ES-Spezifikation. enum , import x = require(...) , module ist die Ausnahme von dieser Regel, aber sie stammen aus der frühen Zeit von TypeScript.

2. Wenn Sie Marco verwenden möchten, um verschiedene Dateien zu kreuzen, um verschiedene JS-Dateien zu generieren, ist es unmöglich, die gesamte Typsyntax dummerweise zu löschen, um die JavaScript-Datei zu erhalten.

3. Marcos kann die Analyse- und Kompilierzeit erhöhen und wahrscheinlich missbraucht werden.

4. Wenn Marco basierend auf den Typinformationen verschiedene JS-Dateien ausgeben kann, wird es Babel unmöglich, mit dieser Syntax umzugehen. Dieses Verhalten verstößt also gegen die isolatedModules Regel (Ausnahme: const enum und module )

5. Wenn Marco nur einen "Type Level Marco" machen kann und von Babel sicher gelöscht werden kann, wird es viel nutzlos, aber immer noch nützlich für höherwertige / programmatische Typen. Daher verstößt es nicht gegen irgendwelche Ziele, aber ich bezweifle, dass das TypeScript-Team an der Idee interessiert sein wird. (Ich habe eine Demo unter https://github.com/Jack-Works/typescript-marco-demo/blob/master/marco-test.ts erstellt).

@Jack-Works Ich verstehe deine Punkte nicht. Vielleicht meinen Sie, dass Makrose den Parser erweitern und neue Synatx erstellen?

Für mich sind Makros nur AST -> AST-Funktion, die irgendwie den vorherigen Typechecker ausführt und daher neue AST-Knoten erstellen kann, die regelmäßig typgeprüft werden. Es erstellt jedoch keine neue Syntax - die Eingabe ist reguläres AST, die Ausgabe auch. Es erstellt neue Knoten in AST.

Die Diskussion wird für diesen Thread nicht zum Thema gehören und vielleicht auf dem #compiler-Kanal in Discord fortgesetzt werden?

Kann #38597 in TypeScript 4.0 aufgenommen werden?

@DanielRosenwasser

undefined auf Index-Signaturen ist ein Beispiel für etwas Interessantes, aber wir wollen kein Verhalten hinzufügen, das es 90 % der Menschen erschwert, die bereits mit den aktuellen Annahmen arbeiten.

Nur neugierig, woher weißt du, dass es 90% der Leute sind?

@wongjiahau die Nummer wurde zur Erklärung beiläufig erfunden. Ich bin mir nicht sicher, ob das der konkrete Punkt ist, nach dem Sie fragen.

Nur als Vorwarnung: Unser Team wird am 19. Juni nicht arbeiten, also werden wir den Zeitplan etwas verschieben. Die Beta soll nun bis nächsten Donnerstag, den 25. Juni, ausgeliefert werden.

@DanielRosenwasser Ich versuche darauf hinzuweisen, dass Sie einige erfundene willkürliche Zahlen verwenden, um die Bedeutung der Funktion (# 13778) zu leugnen, die eindeutig mit dem ersten Ziel von Typescript übereinstimmt, das darin besteht , Konstrukte, die wahrscheinlich sind, statisch zu identifizieren Fehler sein .

Bitte verstehen Sie mich nicht falsch, ich schätze die harte Arbeit, die das Kernteam in dieses Projekt gesteckt hat, aber ich denke nur, dass wir es besser hätten machen können, wenn wir uns stattdessen wirklich an den Zielen dieses Projekts ausrichten könnten zuzulassen, dass unbewiesene Aussagen seine Weiterentwicklung behindern.

@wongjiahau Wir sind nicht in ein Meeting gegangen und haben gesagt: „Daniel hat gesagt, die Zahl ist 90 %, das ist über unserem Schwellenwert von 85 %, lass uns diese Funktion nie machen“. Wir untersuchen es immer noch und sind uns der Nachfrage der Entwickler sehr bewusst, aber wir haben auch getestet, wie dieses Feature in der Praxis aussieht, und ich kann Ihnen sagen, dass es nicht schön ist.

Wenn Sie Aussagen wie diese von uns so überanalysieren, werden Sie nur weniger Aussagen von uns erhalten, weil wir Besseres zu tun haben, als im Internet aktiv falsch interpretiert zu werden.

4.0 ist definitiv eher ein Meilenstein als „die nächste Version von 3.9“.

@typescript-bot erstellt Release-4.0

Heya @DanielRosenwasser , ich habe begonnen, den release-4.0 Branch für dich zu erstellen. Hier ist der Link zu meiner besten Vermutung im Protokoll .

@Kingwl Wenn das ein Meilenstein ist, was sind dann diese großen Dinge oder was ist zumindest das Hero Feature? Ich sehe nichts so Großartiges in der Liste der Sprachfunktionen oben in dieser Ausgabe. Nichts Ungewöhnliches im Vergleich zu den meisten 3.x-Versionen.
Natürlich könnte man sagen, dass es nur eine bahnbrechende Änderung ist, die die Veröffentlichung einer Hauptversion erfordert, aber dann ist es schwer, dies als "Meilenstein" zu bezeichnen.

@wgebczyk Meiner Meinung nach sind variadische Tupel mit beschrifteten Tupelelementen der Meilenstein.

@wgebczyk Egal . Aber eigentlich ist Variadic Tuples.

@xiaoxiangmoe @Kingwl Meilenstein ? Zoll-Stein.

Es ist da: https://devblogs.microsoft.com/typescript/announcing-typescript-4-0-beta/#variadic -tuple-types
Wann wird dies eine stabile Version erreichen? Ich kann es kaum erwarten, dies bei der täglichen Codierung in VS Code anzuwenden.

@mk0y laut Eröffnungsnachricht über den 18. August.

@wgebczyk unsere Veröffentlichungen sind zeitbasiert; Jede Version enthält ungefähr drei Monate der Arbeit des Teams. Unsere Meilenstein-Versionierungsrichtlinie (n = n + 0,1) war für die letzten 20 Versionen konsistent, also wird dies hoffentlich irgendwann keine Überraschung mehr für die Leute sein 😅

Würden Sie in Betracht ziehen, den Typ symbol für die Indizierung in den nächsten Nebenversionen zuzulassen? Könnten Sie die Pull-Anforderung 26797 aktualisieren und zusammenführen?

Hallo @DanielRosenwasser , ich habe begonnen, die Versionsnummer von release-4.0 4.0.1-rc zu aktualisieren. Hier ist der Link zu meiner besten Vermutung im Protokoll .

@typescript-bot sync release-4.0

Heya @DanielRosenwasser , ich habe begonnen, release-4.0 für dich mit dem Master zu synchronisieren. Hier ist der Link zu meiner besten Vermutung im Protokoll .

@typescript-bot sync release-4.0

Heya @DanielRosenwasser , ich habe begonnen, release-4.0 für dich mit dem Master zu synchronisieren. Hier ist der Link zu meiner besten Vermutung im Protokoll .

@weswighammmmmmmmmmmmmmmmmmm , der Bot hasst mich ): ): ): ):

Absolut keine Eile, aber ich habe es manuell gemacht und Folgendes abgelegt: https://github.com/microsoft/TypeScript/issues/39869

Gibt es schon irgendwo eine Roadmap für nach 4.0? Ich möchte #37582 verstärken, da es eine immer größer werdende Nachfrage gibt (#39965, #38149, #27481, #39965, #38546). Es sieht für mich nach einem Problem mit vernünftigem Umfang aus.

Nur als Update mussten wir den RC um 2 Tage verschieben, um die Website zu starten, und für andere Änderungen hatten wir das Gefühl, dass wir im RC landen mussten. Wir gehen nicht davon aus, dass uns irgendetwas weiter zurückdrängen wird, aber um sicher zu gehen, geben wir uns weitere 2 Tage Zeit, um Feedback zum RC zu erhalten, und streben stattdessen den 20. an.

@typescript-bot-Bump-Release-4.0

Hallo @DanielRosenwasser , ich habe begonnen, die Versionsnummer von release-4.0 4.0.2 zu aktualisieren. Hier ist der Link zu meiner besten Vermutung im Protokoll .

Es ist der 20. August :)

Heh, hier ist immer noch der 19. August, und selbst in 20 Minuten, denke ich, musst du noch ein bisschen warten. Wir haben nächtliche Veröffentlichungen auf npm, wenn Sie sich keine weitere Minute Zeit nehmen können! 😄

Warten auf die Veröffentlichung, bereits in npm :)

@typescript-bot-Bump-Release-4.0

Hallo @DanielRosenwasser , ich habe begonnen, die Versionsnummer von release-4.0 4.0.3 zu aktualisieren. Hier ist der Link zu meiner besten Vermutung im Protokoll .

@typescript-bot-Bump-Release-4.1

Hallo @DanielRosenwasser , ich habe begonnen, die Versionsnummer von release-4.1 4.1.1-rc zu aktualisieren. Hier ist der Link zu meiner besten Vermutung im Protokoll .

Ach nein

@typescript-bot-Bump-Release-4.0

Hallo @DanielRosenwasser , ich habe begonnen, die Versionsnummer von release-4.0 4.0.4 zu aktualisieren. Hier ist der Link zu meiner besten Vermutung im Protokoll .

@typescript-bot-Bump-Release-4.0

Hallo @DanielRosenwasser , ich habe begonnen, die Versionsnummer von release-4.0 4.0.5 zu aktualisieren. Hier ist der Link zu meiner besten Vermutung im Protokoll .