+ Répondre à la discussion Actualité déjà publiée
  1. #1
    Rédacteur/Modérateur

    Avatar de yahiko
    Homme Profil pro
    Ninja
    Inscrit en
    juillet 2013
    Messages
    1 104
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Ninja

    Informations forums :
    Inscription : juillet 2013
    Messages : 1 104
    Points : 6 111
    Points
    6 111
    Billets dans le blog
    39

    Par défaut TypeScript 2.3 disponible

    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 - Visualiser dans une fenêtre à part
    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 - Visualiser dans une fenêtre à part
    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 - Visualiser dans une fenêtre à part
    1
    2
    3
    async function* asyncGenName() {
        /*...*/
    }
    Voici un exemple combinant les différentes constructions :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    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 - Visualiser dans une fenêtre à part
    (Symbol as any).asyncIterator = Symbol.asyncIterator || Symbol.from("Symbol.asyncIterator");
    ou encore

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    (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 ?
    Tutoriels et FAQ TypeScript

  2. #2
    Chroniqueur Actualités
    Avatar de Michael Guilloux
    Homme Profil pro
    Consultant
    Inscrit en
    juillet 2013
    Messages
    1 368
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 26
    Localisation : Côte d'Ivoire

    Informations professionnelles :
    Activité : Consultant
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : juillet 2013
    Messages : 1 368
    Points : 37 885
    Points
    37 885
    Billets dans le blog
    2

    Par défaut TypeScript 2.3 disponible

    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 - Visualiser dans une fenêtre à part
    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 - Visualiser dans une fenêtre à part
    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
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

  3. #3
    Membre habitué Avatar de benjamin_musique
    Homme Profil pro
    Développeur informatique
    Inscrit en
    avril 2004
    Messages
    48
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : France, Puy de Dôme (Auvergne)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : avril 2004
    Messages : 48
    Points : 141
    Points
    141

    Par défaut

    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!

  4. #4
    Rédacteur/Modérateur

    Avatar de yahiko
    Homme Profil pro
    Ninja
    Inscrit en
    juillet 2013
    Messages
    1 104
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Ninja

    Informations forums :
    Inscription : juillet 2013
    Messages : 1 104
    Points : 6 111
    Points
    6 111
    Billets dans le blog
    39

    Par défaut

    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.
    Tutoriels et FAQ TypeScript

  5. #5
    Membre confirmé
    Avatar de Paleo
    Homme Profil pro
    Développeur Web
    Inscrit en
    septembre 2013
    Messages
    194
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Bénin

    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : septembre 2013
    Messages : 194
    Points : 558
    Points
    558

    Par défaut

    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 ?

  6. #6
    Rédacteur/Modérateur

    Avatar de yahiko
    Homme Profil pro
    Ninja
    Inscrit en
    juillet 2013
    Messages
    1 104
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Ninja

    Informations forums :
    Inscription : juillet 2013
    Messages : 1 104
    Points : 6 111
    Points
    6 111
    Billets dans le blog
    39

    Par défaut

    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.
    Tutoriels et FAQ TypeScript

  7. #7
    Membre confirmé
    Avatar de Paleo
    Homme Profil pro
    Développeur Web
    Inscrit en
    septembre 2013
    Messages
    194
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Bénin

    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : septembre 2013
    Messages : 194
    Points : 558
    Points
    558

    Par défaut

    Merci. J'avais effectivement raté cette discussion.

Discussions similaires

  1. Réponses: 7
    Dernier message: 28/11/2012, 22h34
  2. Réponses: 34
    Dernier message: 21/09/2009, 22h49
  3. Réponses: 0
    Dernier message: 07/02/2009, 15h05
  4. Réponses: 0
    Dernier message: 23/05/2008, 11h26
  5. Réponses: 97
    Dernier message: 03/12/2007, 10h39

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo