Newsletter Developpez.com

Inscrivez-vous gratuitement au Club pour recevoir
la newsletter hebdomadaire des développeurs et IT pro

TypeScript 2.3 disponible en Release Candidate
Avec le support des générateurs et itérateurs asynchrones

Le , par yahiko, Rédacteur/Modérateur
TypeScript 2.3 en Release Candidate


Le 10 avril, l'équipe TypeScript a sorti la RC de la version 2.3 de ce langage, surensemble typé de JavaScript.

Elle peut être installée avec NuGet ou npm :
npm install -g typescript@rc

Le plugin TypeScript 2.3 pour Visual Studio 2015 Update 3 est disponible ici.

Pour les autres éditeurs, il convient de veiller à utiliser la dernière version du compilateur : Visual Studio Code, Sublime Text 3.

L'option --strict

Par défaut, le système de typage de TypeScript est très tolérant afin de permettre aux développeurs de typer graduellement.

Il existe cependant des options au niveau du compilateur pour que celui-ci soit plus restrictif sur la façon de typer. Dans l'esprit dans lequel il a été conçu, le langage encourage les réglages les plus stricts, car ce sont eux qui offrent le plus de garanties quant à la qualité du code produit (en contrepartie, d'un nombre de messages d'erreur plus élevé).

Le problème, c'est qu'au fil du temps, le compilateur s'est vu affublé de beaucoup d'options différentes : --noImplicitAny, --strictNullChecks, --noImplicitThis, et --alwaysStrict sont les options les plus courantes. Seulement, cela nécessite de s'en souvenir et rend de fait TypeScript un peu plus difficile à utiliser.

C'est pourquoi la version 2.3 introduit l'option --strict. Cette option active l'ensemble des restrictions sur l'utilisation des types. Il reste possible de désactiver individuellement chaque restriction à l'aide du fichier projet tsconfig.json :

Code : Sélectionner tout
1
2
3
4
5
6
{
    "compilerOptions": {
        "strict": true,
        "noImplicitThis": false
    }
}
Fichier tsconfig.json avec toutes les restrictions de typage activées, sauf pour --noImplicitThis.

À l'avenir, --strict pourra inclure d'autres vérifications utiles à tous les développeurs, mais qui pourront être désactivées manuellement et explicitement comme dans l'exemple plus haut.

Compatibilité ES3 et ES5 des générateurs & itérateurs

Avant la version 2.3, les générateurs n'étaient pas supportés en ciblant de l'ES3 ou de l'ES5 à cause des boucles for..of qui ne fonctionnaient qu'avec des tableaux en mode ES3/ES5.

Désormais, les générateurs sont disponibles en ES3 et ES5 en utilisant l'option --downlevelIteration, rendant plus simple l'utilisation de bibliothèques comme redux-saga.

Générateurs et itérateurs asynchrones

Cette version 2.3 de TypeScript permet également d'utiliser des générateurs et itérateurs asynchrones (async) conformément à la proposition TC39.

Les itérateurs asynchrones sont une fonctionnalité ECMAScript à venir qui permet aux itérateurs de produire de façon asynchrone des résultats. Ils peuvent être consommés proprement par des fonctions asynchrones avec une construction syntaxique nommée les boucles asynchrones comme ci-dessous :

Code : Sélectionner tout
1
2
3
for await (let item of items) {
    /*...*/
}
Les générateurs asynchrones sont des générateurs qui peuvent être mis en pause (await) à n'importe quel endroit. Ils sont déclarés en utilisant la syntaxe suivante :

Code : Sélectionner tout
1
2
3
async function* asyncGenName() {
    /*...*/
}
Voici un exemple combinant les différentes constructions :

Code : Sélectionner tout
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
// Renvoie une Promise qui est résolue après un certain délai.
function sleep(milliseconds: number) {
    return new Promise<void>(resolve => {
        setTimeout(resolve, milliseconds);
    });
}
 
// Ceci convertit l'itérable passé en argument en un itérable asynchrone.
// Chaque élément est retourné (yield) avec un délai.
async function* getItemsReallySlowly<T>(items: Iterable<T>) {
    for (const item of items) {
        await sleep(500);
        yield item;
    }
}
 
async function speakLikeSloth(items: string[]) {
    // Patiente avant chaque itération jusqu'à ce qu'un résultat soit disponible.
    for await (const item of getItemsReallySlowly(items)) {
        console.log(item);
    }
}
 
speakLikeSloth("never gonna give you up never gonna let you down".split(" "));
Il convient de garder à l'esprit que le support des itérateurs asynchrones repose sur l'existence de Symbol.asyncIterator à l'exécution. Un polyfill pour émuler Symbol.asyncIterator peut être nécessaire, ce qui pour des cas d'utilisation basiques pourrait ressembler à ceci :

Code : Sélectionner tout
(Symbol as any).asyncIterator = Symbol.asyncIterator || Symbol.from("Symbol.asyncIterator");
ou encore

Code : Sélectionner tout
(Symbol as any).asyncIterator = Symbol.asyncIterator || "__@@asyncIterator__";
Pour compiler en ES5 ou antérieur, l'option --downlevelIteration est également nécessaire ainsi que l'option --lib incluant esnext.

source : Blog officiel de Microsoft

Attendiez-vous ces nouvelles fonctionnalités ?


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de Michael Guilloux Michael Guilloux - Chroniqueur Actualités https://www.developpez.com
le 28/04/2017 à 15:20
La version stable de TypeScript 2.3 est disponible
Le point des nouveautés du surensemble typé de JavaScript

Après la release candidate (RC) sortie il y a deux semaines, la version stable de TypeScript 2.3 est maintenant disponible. Comme nous l’avons annoncé, cette version du surensemble typé de JavaScript apporte comme nouveautés l'option --strict, la compatibilité ES3 et ES5 des générateurs et itérateurs, et des générateurs et itérateurs asynchrones, présentés à la sortie de la RC.

Avec la sortie de TypeScript 2.3, Microsoft a toutefois tenu à mettre en évidence d’autres nouveautés. Par exemple, avec la nouvelle option --strict activée par défaut, tsc --init a une sortie améliorée. Les fichiers tsconfig.json par défaut générés par tsc --init incluent maintenant un ensemble d'options de compilation communes avec leur description en commentaires. Étant donné que les utilisateurs ignorent souvent les types d'options que TypeScript met à leur disposition, Microsoft a décidé de profiter de la sortie de --init de TypeScript pour lister de manière explicite les options potentielles dans des commentaires. À titre d'exemple, la sortie de tsconfig.json ressemblera à ce qui suit :

Code : Sélectionner tout
1
2
3
4
5
6
7
8
9
10
11
12
13
14
{
  "compilerOptions": {
    /*  Basic  Options */
    "target": "es5",              /* Specify ECMAScript target version: 'ES3' (default), 'ES5', 'ES2015', 'ES2016', 'ES2017', or 'ESNEXT'. */
    "module": "commonjs",         /* Specify module code generation: 'commonjs', 'amd', 'system', 'umd' or 'es2015'. */
    // "lib": [],                 /* Specify library files to be included in the compilation:  */
    // "allowJs": true,           /* Allow javascript files to be compiled. */
    // "checkJs": true,           /* Report errors in .js files. */
    // "jsx": "preserve",         /* Specify JSX code generation: 'preserve', 'react-native', or 'react'. */
    // "declaration": true,       /* Generates corresponding '.d.ts' file. */
    // "sourceMap": true,         /* Generates corresponding '.map' file. */
    // ...
  }
}

Une autre nouveauté intéressante porte sur la vérification de type dans des fichiers JavaScript avec // @ts -check et --checkJs. Par défaut, le compilateur TypeScript ne signale aucune erreur dans les fichiers .js, y compris en utilisant --allowJs (qui permet aux fichiers JavaScript d'être compilés).

Avec TypeScript 2.3, les erreurs de vérification de type peuvent maintenant être signalées dans les fichiers .js avec l'option --checkJs. Vous pouvez ignorer la vérification d'un fichier en ajoutant un commentaire avec // @ts -nocheck en haut du fichier. À l'inverse, vous pouvez choisir de vérifier seulement quelques fichiers .js en ajoutant un commentaire //@ ts -check sans définir l'option --checkJs. Vous pouvez également ignorer les erreurs sur des lignes spécifiques en ajoutant // @ ts -ignore sur la ligne précédente.

Code : Sélectionner tout
1
2
3
4
5
6
7
8
9
// @ts-check
 
/**
 * @param {string} input
 */
function foo(input) {
    input.tolowercase()
    //    ~~~~~~~~~~~ Error! Should be toLowerCase
}

Vous trouverez plus de détails sur les autres nouveautés introduites dans TypeScript sur GitHub.

Sources : Microsoft, GitHub

Utilisez-vous TypeScript ? Qu'en pensez-vous ?
Quelles fonctionnalités vous semblent les plus intéressantes dans cette version ?

Voir aussi :

Visual Studio Code 1.11 est disponible, avec TypeScript 2.2.2, un nouvel éditeur de raccourcis, une amélioration pour la recherche de texte et plus
Après avoir réécrit Angular en TypeScript, Google approuve le surensemble JavaScript de Microsoft pour ses développements internes
Avatar de benjamin_musique benjamin_musique - Membre habitué https://www.developpez.com
le 15/05/2017 à 10:11
Je l'utilise dans un 1er projet avec Angular (je travaille pour une grande entreprise industrielle).
Le typage étant optionnel pour moi ça n'a que des avantages
Même si on a peur pour sa pérennité, les personnes ayant investi sur Silverlight me comprendront!
Avatar de yahiko yahiko - Rédacteur/Modérateur https://www.developpez.com
le 21/05/2017 à 1:09
Silverlight, auquel je n'ai jamais cru, était une techno propriétaire.
TypeScript à contrario, est un langage open source qui a un réel souci des standards actuels du Web, au point même dans les réflexions actuelles sur la feuille de route, de limiter au maximum les extensions de la syntaxe du langage sur des aspects "peu JavaScript", comme les classes par exemple.
Personnellement, je trouve cela un peu dommage, mais je peux comprendre la logique de l'équipe TypeScript de coller au maximum à JavaScript et aux prochaines recommandations du comité ECMAScript.
Avatar de Paleo Paleo - Membre confirmé https://www.developpez.com
le 22/05/2017 à 10:57
Citation Envoyé par benjamin_musique Voir le message
Je l'utilise dans un 1er projet avec Angular (je travaille pour une grande entreprise industrielle).
Le typage étant optionnel pour moi ça n'a que des avantages
Même si on a peur pour sa pérennité, les personnes ayant investi sur Silverlight me comprendront!
Les choix de design de TypeScript en font une technologie pérenne. Vos mauvaises surprises viendront d'Angular.

Citation Envoyé par yahiko Voir le message
au point même dans les réflexions actuelles sur la feuille de route, de limiter au maximum les extensions de la syntaxe du langage sur des aspects "peu JavaScript", comme les classes par exemple.
Sur quelle discussion ?
Avatar de yahiko yahiko - Rédacteur/Modérateur https://www.developpez.com
le 29/05/2017 à 14:40
Je faisais implicitement référence à un long débat sur les classes partielles (partial classes) qui a été tranché récemment par l'un des collaborateurs Microsoft de l'équipe TypeScript.

Voici son commentaire censé clore le débat :
Citation Envoyé par RyanCavanaugh
TL;DR: This isn't happening. If you're down here at comment number 189 and want to register your disapproval with that, please do read the entire thread first, because the very good reasons for not adding this have been extensively covered above.

Our interpretation of this situation is as follows:

* TypeScript already has too many TS-specific class features (constructor property declarations, member initializers, non-finalized decorators, access modifiers, implements, etc.) for something that was really intended to just be "ES6 + Types". Part of that is our fault (our original design direction was generally too OOP) and part of that is ES6's fault (the class proposal moved around a lot five years ago and we ended up having features that didn't make it). Adding yet another TS-specific class feature is another straw on the camel's back that we should avoid if we can.

* Unambiguously, the future of JavaScript is modules. Partial classes only make sense and operate well in the "global soup" model. Allowing partial classes spanning multiple modules is a recipe for disaster as the loading order is not predictable. Adding a feature that only works well in a global-only universe isn't a good use of time.

* C# has it but we're not here to reinvent C#. Seriously!

* The "generated code" scenario isn't compelling on the merits. Any plausible emit for partial classes would restrict property initializers and constructor code to exactly one declaration, and this would be a dealbreaker for .Designer.cs-style setups as both the user code and the generated code would likely need initializers or constructor logic.

* There are many, many other compositional mechanisms available in JS - mixins, Object.assign, etc.. The scenario that led to this feature in C# was driven by constraints that simply aren't present in JS.

* The current workaround of interface + prototype.method = ... does enable the generated-code scenario just as well as partial class would. It's weird to write that code by hand but there's no problem for generating code differently, so if you really think a split-file generated code setup is the only way to solve your problem (I'm skeptical) then that method is available to you.

* We consider ES6 to be the arbiter of "must have" for classes. There's nothing special about TypeScript (other than its appeal to C# programmers) that make it need partial classes any more than non-typed JavaScript would. So if there's some scenario that really knocks it out of the park for adding partial classes, then that scenario ought to be able to justify itself through the TC39 process. If that gains traction we'd be happy to weigh in with input on it, but this doesn't even seem to be on anybody's radar.
Avatar de Paleo Paleo - Membre confirmé https://www.developpez.com
le 30/05/2017 à 8:19
Merci. J'avais effectivement raté cette discussion.
Offres d'emploi IT
Développeur confirmé (H/F)
IT-CE - Provence Alpes Côte d'Azur - Aix-en-Provence (13100)
Ingénieur de développement (H/F)
IT-CE - Nord Pas-de-Calais - Lille (59000)
Ingénieur développeur java / web (H/F)
PROTECTIC - Ile de France - Puteaux (92800)

Voir plus d'offres Voir la carte des offres IT
Responsables bénévoles de la rubrique TypeScript : Xavier Lecomte - Lana Bauer -