<p>Plan d'itération TypeScript 4.0</p>

Envisageriez-vous d'inclure https://github.com/microsoft/TypeScript/pull/29818 dans 4.0 peut-être derrière le drapeau expérimental ?

Cela se complique par le changement de définition de la fonction d'usine en soi.

Il pourrait cependant être intéressant d'introduire une définition de type virtuel de fabrique _séparée_ ; disons, JSX.Factory , ou React.JSX.Factory , que TypeScript pourrait alors utiliser pour l'inférence. Je ne suis pas tout à fait sûr que la simple traduction de la grammaire JSX en appels de fonction soit suffisante ou efficace, mais comme il s'agit d'un type virtuel, il ne doit pas correspondre à une entité JavaScript concrète. Le risque, bien sûr, est de se retrouver dans la même situation que nous avons maintenant, avec un tas de types virtuels qui ont fini par limiter la sécurité des types, non seulement des enfants, mais de plusieurs fonctionnalités introduites après React 15.

Envisageriez-vous également d'inclure https://github.com/microsoft/TypeScript/pull/24738 dans la version 4.0 ?

Je suis un peu triste de ne voir aucune mention de # 33038 [👍 140 et un véritable PR par votre propre @weswigham] ou # 202 [👍 390] alors que des billets comme # 15230 [👍 27] sont considérés comme "très demandés". Je me rends compte que vous ne pouvez pas vraiment comparer ou hiérarchiser sur la base des "j'aime", mais ce serait formidable s'il y avait une mise à jour de la feuille de route à ce sujet, d'autant plus que la version 4.0 semble être une belle opportunité d'introduire une fonctionnalité comme celle-ci. 🙏

Problème d'environ 3,5 ans en attente de commentaires avec près de 200 commentaires # 13778 avec des typages inexacts fournis pour des choses comme la déstructuration de tableaux. Pwetty pwease pouvons-nous mettre en œuvre le correctif 🙏

J'apprécie que les gens soulèvent occasionnellement des problèmes qui, selon eux, nécessitent une attention particulière sur les feuilles de route et les plans d'itération, mais je pense que je dois être clair ici - cette section "enquêter sur les corrections de bogues à forte demande" a été déterminée en examinant les problèmes qui causaient clairement beaucoup de papiers découpés mais dont la portée semblait raisonnable. Nous sommes certainement toujours conscients des problèmes mentionnés, mais certains d'entre eux ne sont pas aussi étendus et n'ont pas de résultat idéal clair.

Exemples:

• Les marques nominales seraient bien, mais cela composerait-il avec l'orientation future du langage autour de la nominalité ? J'ai même ce souci avec les types d'espace réservé comme la personne qui l'a proposé.
• undefined sur les signatures d'index est un exemple de quelque chose d'intéressant, mais nous ne voulons pas ajouter de comportement qui rende la tâche plus difficile pour 90 % des personnes qui opèrent déjà selon les hypothèses actuelles. Trouver une approche qui compose et permet aux utilisateurs d'adopter progressivement ces vérifications n'est pas quelque chose d'évident pour nous. Même si c'est techniquement possible avec un tas de types conditionnels et des vérifications spéciales du compilateur, ces solutions ont tendance à être très clairement hackées et à se décomposer rapidement.

Les marques nominales seraient bien, mais cela composerait-il avec l'orientation future du langage autour de la nominalité ?

@DanielRosenwasser quelle est la future direction linguistique dans votre vision ?

Je suppose que je vais donner un peu de contexte sur où mon esprit est avec la nominalité. Il y a beaucoup d'idées différentes que les gens ont à l'esprit lorsqu'ils posent des questions sur les types nominaux, y compris

• Nominalité "traditionnelle" basée sur les déclarations (par exemple, ce que vous voyez dans la plupart des langages OO)
• Types opaques (types dont le contenu est entièrement inconnu à l'extérieur)
• Alias ​​distincts (membre unique struct s en C/C++/C#, newtype en Haskell, classes inline en Kotlin)
• Unités de mesure (un moyen d'encoder l'analyse dimensionnelle dans le langage)

Il existe des nuances entre certains d'entre eux (par exemple , les déclarations de type d'espace réservé - une sorte de variante de types opaques qui retombent sur un type d'implémentation), puis il existe différentes directions qui mélangent chacun d'entre eux.

@RyanCavanaugh avait une grande analogie à ce sujet où 3 enfants demandent à leurs parents un animal de compagnie. On veut un chien, on veut un chat, on veut un poisson. Ils demandent à leurs parents "quand est-ce qu'on va avoir un animal de compagnie !?" De toute évidence, ils sont tous d'accord pour dire qu'ils veulent un animal de compagnie, mais chacun veut un animal de compagnie différent !

Est-ce que j'aime les types de marque ? Je fais! Les types de marque permettent d'obtenir quelque chose comme des alias distincts et correspondent à ce que recherchent la plupart des utilisateurs. Mais je ne pense pas que ce soit la bonne façon d'y penser. Il y a plus d'espace de conception à étoffer avec de nombreux compromis connus, et rien ne me donne l'impression que nous devons précipiter une solution dès que possible.

J'aimerais si nous pouvions obtenir https://github.com/microsoft/TSJS-lib-generator/pull/858 dans TypeScript 4.0 .

@DanielRosenwasser tout d'abord merci pour la rédaction 🙇

Pouvez-vous élaborer un peu sur les cas d'utilisation que les types nominaux traitent réellement pour TypeScript ?

Tout d'abord : n'hésitez pas à m'envoyer un mur de texte géant ou un dépôt et je le lirai :]

Je ne parle pas de types opaques comme les types d'espace réservé - je veux dire ce que vous appelez les types nominaux "traditionnels".

J'ai toujours pensé que les types nominaux étaient antithétiques à JavaScript et c'est pourquoi les tentatives précédentes n'ont pas vraiment bien fonctionné. Il existe des moyens de le faire fonctionner assez bien (les protocoles dans Swift et les classes de types dans Haskell me viennent à l'esprit comme "Nominal mais extensible de l'extérieur") et je suis sûr que vous connaissez la plupart des méthodes "bien établies" (je supposons que "unités de mesure" est un clin d'œil F#).

J'ai trouvé beaucoup de gens demandant des types nominaux (comme dans "traditionnels") mais pas beaucoup d'articles sur _why_.

Au fil du temps, nous avons vu de moins en moins de personnes demander des types nominaux "traditionnels", peut-être parce que collectivement la communauté a construit un mode mental pour les types structurels. Il y a des endroits où les types agissent vraiment nominalement (quand instanceof est impliqué ou quand il y a des privés). Une partie de cela est capturée avec une meilleure analyse du flux de contrôle et des vérifications de compatibilité, mais ce n'est pas parfait.

Certains des cas d'utilisation "traditionnels" sont les mêmes que ceux d'un type d'encapsuleur nominal sans surcharge (par exemple newtype ), et la plupart du temps, l'intention est d'assurer une gestion spéciale pour des choses comme file chemins, chaînes non fiables, etc.

J'ai l'impression que Typescript est déjà assez expressif. Ce que j'aimerais personnellement voir, c'est une meilleure intégration des outils.

• prise en charge d'ESM https://github.com/microsoft/TypeScript/pull/35148 https://github.com/microsoft/TypeScript/issues/16577
• plugins du compilateur https://github.com/microsoft/TypeScript/issues/16607 https://github.com/microsoft/TypeScript/issues/38736
• fil pnp https://github.com/microsoft/TypeScript/issues/28289 https://github.com/microsoft/TypeScript/pull/35206

En raison de ce qui précède, il est courant de voir des solutions maladroites et hacky. La plupart des projets de réaction ont babel inclus pour le chargeur à chaud (plugins du compilateur), certains systèmes CSS nécessitent également babel pour les transformations au moment de la compilation. L'utilisation de modules pnp, esm ou même CSS nécessite plus d'outils et de solutions de contournement pour les limitations tsc.

Il est également frustrant que pour certains de ces problèmes, la communauté ait proposé des solutions concrètes sous forme de relations publiques ou de propositions, mais celles-ci ont été rejetées ou bloquées pendant des années. En tant que praticien, il devient de plus en plus difficile d'utiliser TS dans le contexte d'un écosystème plus large.

Quoi qu'il en soit, je ne suis qu'une personne au hasard sur Internet.

@DanielRosenwasser peut-être que https://github.com/microsoft/TypeScript/pull/29374 pourrait être révisé à temps pour la version 4.0 ? Je pense qu'il couvre beaucoup (la plupart ?) des cas this -avant- super que les gens ont tendance à poser.

Veuillez reconsidérer l'inclusion de la prise en charge du référencement des modules ES avec un chemin de fichier comprenant l'extension de fichier. Cela donnera un grand coup de pouce pour uniformiser les règles du jeu du code multi-environnement.

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

Merci de vous concentrer sur l'outillage autour de la dactylographie ! J'espérais que vous pourriez envisager de fournir une intégration plus étroite avec https://github.com/microsoft/tsdoc. Beaucoup d'autres langages modernes comme go et rust fournissent des outils de documentation prêts à l'emploi et encouragent les développeurs à écrire des commentaires standard, mais le tapuscrit fait défaut à cet égard.

Ce serait super bien si # 31445 pouvait être récupéré, cela a été une rupture pour nous et je crois que beaucoup de gens (en fonction du nombre de références de ce problème) !

https://github.com/microsoft/TypeScript/pull/38967 peut-il être inclus dans TypeScript 4.0 , et peut-être aussi https://github.com/microsoft/TypeScript/pull/35608 .

J'ai trouvé que les gens demandent que tout soit inclus dans la version 4.0 😆

Vous avez l'impression que TS perd de son élan ? Des affectations de fusion et de court-circuit nulles pour la prochaine version _major_, 4.0.0 ? Plus de grands objectifs et d'idées d'ambition ?

Pour la prochaine majeure, je m'attends à :

• Type de typage supérieur
• Dactylographie dépendante ? Fonctions au niveau du type ? (Ok, celui-ci peut être pour 5.0.0)
• Typage nominal
• Macros
• Prise en charge des transformateurs en tsconfig.json
• Compilation vers WASM (de certains sous-ensembles de langage)

@canonic-epicure D'accord, actuellement cela ressemble plus à un 3.10 pour la prochaine version

Vous avez l'impression que TS perd de son élan ? Des missions de fusion et de court-circuit nulles pour la prochaine version majeure 4.0.0 ? Plus de grands objectifs et d'idées d'ambition ?

TypeScript ne suit pas le semver. Il n'y a pas de v0.10, v1.10, v2.10 ou v3.10. Il s'agit donc en fait d'une étape normale. C'est un peu étrange que les gens s'attendent à tant de changements dans la version 4.0 mais ne disent rien dans la version 3.9 ou dans le plan d'itération précédent. 🙈

Fonctions au niveau du type

type X<T> = T peut le faire à un certain niveau. (ne prenant pas en charge les fonctions d'ordre supérieur.)

Macros

IMO, cela ne satisfait pas l'objectif du Typescript.

Prise en charge des transformateurs dans tsconfig.json

Essayez : https://github.com/cevek/ttypescript

Compilation vers WASM (de certains sous-ensembles de langage)

Cherchez-vous https://www.assemblyscript.org/

Ok, donc la 4.0.0 n'est qu'une prochaine version mineure, bon à savoir.

En ce qui concerne les "macroses ne satisfont pas l'objectif TS" et "utiliser ttypescript pour les transformateurs" ( ts-patch fonctionne mieux d'ailleurs) - cela ressemble au mouvement jedi - "ce n'est pas la fonctionnalité dont vous avez besoin". Non, macros et transformateurs prêts à l'emploi s'il vous plaît. Il a été demandé il y a des années.

Je veux aussi marco dans TypeScript mais il y a vraiment de nombreuses raisons contre cela.

1. si Marco peut générer un code JavaScript différent, il crée une nouvelle syntaxe de niveau non-type, il s'agit donc d'une extension de la spécification ES. enum , import x = require(...) , module est l'exception à cette règle mais ils viennent des débuts de TypeScript.

2. si vous souhaitez utiliser Marco cross différents fichiers pour générer différents fichiers JS, il est alors impossible de supprimer bêtement toute la syntaxe de type pour obtenir le fichier JavaScript.

3. Marcos peut augmenter le temps d'analyse et de compilation, et risque d'être abusé.

4. Si Marco peut émettre différents fichiers JS en fonction des informations de type, il sera impossible à Babel de gérer cette syntaxe. Ce comportement enfreint donc la règle isolatedModules (exception : const enum et module )

5. Si Marco ne peut faire qu'un "Marco de niveau de type" et peut être effacé par Babel en toute sécurité, cela devient beaucoup inutile mais toujours utile pour les types d'ordre supérieur / programmatiques. Par conséquent, cela ne viole aucun objectif, mais je doute que l'équipe TypeScript s'intéresse à l'idée. (J'ai fait une démo sur https://github.com/Jack-Works/typescript-marco-demo/blob/master/marco-test.ts).

@Jack-Works Je ne comprends pas vos arguments. Peut-être voulez-vous dire que les macros étendront l'analyseur et créeront un nouveau synatx ?

Pour moi, les macros ne sont que la fonction AST -> AST, qui exécute le vérificateur de type précédent d'une manière ou d'une autre, elle peut donc créer de nouveaux nœuds AST qui seront vérifiés régulièrement. Cependant, cela ne crée pas de nouvelle syntaxe - l'entrée est de l'AST normal, la sortie aussi. Il crée de nouveaux nœuds dans AST.

La discussion sera hors sujet pour ce fil, peut-être à poursuivre sur le canal #compiler en discord ?

Le #38597 peut-il être inclus dans TypeScript 4.0 ?

@DanielRosenwasser

undefined sur les signatures d'index est un exemple de quelque chose d'intéressant, mais nous ne voulons pas ajouter de comportement qui rende la tâche plus difficile pour 90 % des personnes qui opèrent déjà selon les hypothèses actuelles.

Juste curieux, comment savez-vous que c'est 90% des gens ?

@wongjiahau le nombre a été inventé avec désinvolture pour des raisons d'explication. Je ne sais pas si c'est le point précis que vous posez.

Petit rappel : notre équipe ne travaillera pas le 19 juin, nous allons donc repousser un peu le planning. La version bêta devrait maintenant être expédiée d'ici jeudi prochain, le 25 juin.

@DanielRosenwasser J'essaie de souligner que vous utilisez des nombres arbitraires inventés pour nier l'importance de la fonctionnalité (# 13778) qui s'aligne clairement sur le premier objectif de Typescript, qui est d' identifier statiquement les constructions susceptibles de être des erreurs .

S'il vous plaît, ne vous méprenez pas, j'apprécie le travail acharné qui a été mis dans ce projet par l'équipe de base, mais je pense simplement que nous aurions pu l'améliorer si nous pouvions être vraiment alignés sur les objectifs de ce projet à la place de laisser des déclarations non prouvées entraver son avancement.

@wongjiahau , nous ne sommes pas allés à une réunion en disant "Daniel a dit que le nombre était de 90 %, c'est au-dessus de notre seuil de 85 %, ne faisons jamais cette fonctionnalité". Nous l'étudions toujours et nous sommes très conscients de la demande des développeurs, mais nous avons également testé à quoi ressemble cette fonctionnalité dans la pratique et je peux vous dire que ce n'est pas joli.

Si vous allez suranalyser des déclarations comme celle-ci de notre part, vous obtiendrez simplement moins de déclarations de notre part, car nous avons mieux à faire que d'être activement mal interprétés sur Internet.

4.0 est définitivement une étape importante plutôt que "la prochaine version de 3.9".

@typescript-bot crée la version-4.0

Heya @DanielRosenwasser , j'ai commencé à créer la branche release-4.0 pour vous. Voici le lien vers ma meilleure estimation du journal .

@Kingwl s'il s'agit d'une étape importante, alors quelles sont ces grandes choses ou au moins quelle est la fonctionnalité Hero? Je ne vois rien d'aussi génial dans la liste des fonctionnalités linguistiques en haut de ce numéro. Rien d'inhabituel comparé à la plupart des versions 3.x.
Bien sûr, vous pourriez dire que c'est juste un changement de rupture qui nécessite la publication d'une version majeure, mais il est alors difficile de l'appeler "jalon".

@wgebczyk À mon avis, les tuples variadiques avec des éléments de tuple étiquetés sont le jalon.

@wgebczyk Peu importe. Mais en réalité, les tuples variadiques le sont.

@xiaoxiangmoe @Kingwl jalon ? pouce-pierre.

C'est là : https://devblogs.microsoft.com/typescript/announcing-typescript-4-0-beta/#variadic -tuple-types
Quand cela atteindra-t-il une version stable ? J'ai hâte d'appliquer cela dans le codage quotidien dans VS Code.

@ mk0y selon le message d'ouverture du 18 août.

@wgebczyk nos versions sont basées sur le temps ; chaque version contient environ trois mois de travail de l'équipe. Notre politique de gestion des versions d'étape (n = n + 0,1) a été cohérente pour les 20 dernières versions, donc j'espère que cela cessera d'être une surprise pour les gens à un moment donné 😅

Envisageriez-vous d'autoriser l'indexation du type symbol dans les prochaines versions mineures ? Pourriez-vous actualiser et fusionner la pull request 26797 ?

Heya @DanielRosenwasser , j'ai commencé à mettre à jour le numéro de version de release-4.0 à 4.0.1-rc pour vous. Voici le lien vers ma meilleure estimation du journal .

@typescript-bot synchronisation version-4.0

Heya @DanielRosenwasser , j'ai commencé à synchroniser release-4.0 avec master pour vous. Voici le lien vers ma meilleure estimation du journal .

@typescript-bot synchronisation version-4.0

Heya @DanielRosenwasser , j'ai commencé à synchroniser release-4.0 avec master pour vous. Voici le lien vers ma meilleure estimation du journal .

@weswighammmmmmmmmmmmmmmmmmm , le bot me déteste ): ): ): ):

Absolument pas pressé, mais je l'ai fait manuellement et j'ai déposé ceci : https://github.com/microsoft/TypeScript/issues/39869

Existe-t-il déjà une feuille de route pour l'après 4.0 quelque part ? J'aimerais booster le #37582 car il y a une demande de plus en plus croissante (#39965, #38149, #27481, #39965, #38546). Cela me semble être un problème de portée raisonnable.

Juste comme mise à jour, nous avons dû déplacer le RC de 2 jours pour le lancement du site Web et pour d'autres changements, nous avons estimé que nous devions atterrir dans le RC. Nous ne prévoyons pas que quoi que ce soit nous repousse beaucoup plus loin, mais pour être sûr, nous allons nous donner encore 2 jours pour avoir des retours sur le RC, et viser le 20 à la place.

@typescript-bot bump release-4.0

Heya @DanielRosenwasser , j'ai commencé à mettre à jour le numéro de version de release-4.0 à 4.0.2 pour vous. Voici le lien vers ma meilleure estimation du journal .

c'est le 20 août :)

Heh, c'est toujours le 19 août ici, et même dans 20 minutes je pense qu'il va falloir patienter encore un peu. Nous avons des sorties nocturnes sur npm si vous ne pouvez pas prendre une minute de plus ! 😄

En attendant la sortie, déjà sorti en npm :)

@typescript-bot bump release-4.0

Heya @DanielRosenwasser , j'ai commencé à mettre à jour le numéro de version de release-4.0 à 4.0.3 pour vous. Voici le lien vers ma meilleure estimation du journal .

@typescript-bot bump release-4.1

Heya @DanielRosenwasser , j'ai commencé à mettre à jour le numéro de version de release-4.1 à 4.1.1-rc pour vous. Voici le lien vers ma meilleure estimation du journal .

Oh non

@typescript-bot bump release-4.0

Heya @DanielRosenwasser , j'ai commencé à mettre à jour le numéro de version de release-4.0 à 4.0.4 pour vous. Voici le lien vers ma meilleure estimation du journal .

@typescript-bot bump release-4.0

Heya @DanielRosenwasser , j'ai commencé à mettre à jour le numéro de version de release-4.0 à 4.0.5 pour vous. Voici le lien vers ma meilleure estimation du journal .