La version stable de TypeScript 2.3 est disponible :
Le point des nouveautés du surensemble typé de JavaScript

Le , par Michael Guilloux, Chroniqueur Actualités
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


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


 Poster une réponse

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
STAGE - Applications physiques 3D interactives
- Ile de France - (78946)
Atos - Midi Pyrénées - Toulouse (31000)
MR Search - Ile de France - Paris (75004)

Voir plus d'offres Voir la carte des offres IT
Contacter le responsable de la rubrique Accueil