Planche de travailExtensions
Amélioration de la vue Extensions lors du redimensionnement. Dans la courte vidéo suivante, la vue Extensions avec la largeur par défaut affiche tous les détails (auparavant, l'icône, les évaluations et le nombre d'installations n'étaient pas affichés). Au fur et à mesure que la vue rétrécit, une icône d'extension plus petite s'affiche et lorsque sa largeur diminue davantage, l'icône et les notes sont masquées.
La vue Extensions affiche désormais un survol personnalisé sur une extension. Ce survol riche comprend la description complète de l'extension et d'autres informations utiles telles que les raisons pour lesquelles une extension est désactivée ou recommandée.
Vous pouvez désormais vérifier l'état d'exécution d'une extension dans le nouvel onglet État d'exécution du volet d'extension. Les informations d'état incluent son heure d'activation, s'il est activé au démarrage et s'il contient des avertissements ou des erreurs. Certaines de ces informations sont affichées dans la vue Extensions et son survol (illustré dans l'image ci-dessus).
L'onglet Détails du volet Extension affiche désormais les catégories, les liens vers les ressources et d'autres informations telles que les dates de publication et de mise à jour de l'extension. La sélection d'une catégorie affichera les autres extensions de cette catégorie dans la vue Extensions.
Éditeur de paramètres
L'éditeur de paramètres prend désormais en charge la validation sur les objets. La validation recherche les erreurs de type pouvant être introduites lors de la modification directe du fichier JSON.
Les paramètres de tableau prennent désormais en charge le glisser-déposer en mode non-édition. De plus, les paramètres de tableau d'énumération avec la propriété uniqueItems définie sur true n'affichent désormais que les options restantes plutôt que toutes les options dans les listes déroulantes.
L'éditeur de paramètres prend également désormais en charge les paramètres de chaîne multiligne, où la valeur est rendue dans une zone de texte multiligne au lieu d'une zone de saisie sur une seule ligne.
Prise en charge des Notebook Jupyter
Ce mois-ci, Microsoft a déplacé le code qui gère la lecture des fichiers *.ipynb de l'extension Jupyter Notebook vers une nouvelle extension intégrée. Cela signifie que vous pouvez désormais ouvrir les notebooks Jupyter dans une nouvelle installation de VS Code, sans avoir à installer l'extension Jupyter complète. Cependant, si vous souhaitez exécuter des cellules ou afficher des sorties qui utilisent des ipywidgets ou d'autres types de rendu complexes, vous devrez installer l'extension Jupyter.
Éditeur
Naviguer entre les régions de pliage
Il existe de nouvelles commandes pour définir l'emplacement du curseur sur un pli correspondant*:
- Aller au pli suivant (editor.gotoNextFold)
- Aller au dossier précédent (editor.gotoPreviousFold)
- Accédez au dossier parent (editor.gotoParentFold)
Les commandes n'ont actuellement pas de raccourcis clavier par défaut, mais vous pouvez ajouter vos propres raccourcis clavier via Préférences*: Ouvrir les raccourcis clavier (Ctrl+K Ctrl+S).
Plier automatiquement les importations
Utilisez le paramètre editor.foldingImportsByDefault pour plier automatiquement les instructions d'importation. L'état du pli est stocké une fois qu'un fichier a été ouvert une fois. La fonctionnalité marche avec TypeScript, JavaScript, Java, C#, C++ et avec tous les langages qui ont un fournisseur de plage de pliage qui annote les instructions d'importation avec FoldingRangeKind.Imports.
Terminal
Faites glisser et déposez les terminaux à travers les fenêtres
Faites glisser et déposez les terminaux de la liste des onglets ou de la zone de l'éditeur d'une fenêtre vers la liste des onglets, la zone de l'éditeur ou le panneau d'une autre fenêtre.
Suivi des processus enfants et avertissements de fermeture
Les paramètres existants de terminal.integrated.confirmOnExit et de nouveau terminal.integrated.confirmOnKill utilisent le suivi des processus enfants pour afficher un avertissement lorsque vous essayez de fermer un terminal qui a des processus enfants sous le processus shell. Par défaut, ce suivi n'affecte que les terminaux de la zone de l'éditeur mais peut désormais être configuré pour afficher des avertissements pour tous les terminaux ou ceux de la zone du panneau.
Définir le profil de terminal contribué par défaut
Les profils de terminaux fournis par les extensions peuvent désormais être définis comme profil par défaut. Le profil de terminal par défaut est indiqué par le suffixe par défaut dans la liste déroulante du terminal.
Débogage
Bouton Exécuter/Déboguer amélioré dans le titre de l'éditeur
Dans la version de février, l'équipe a introduit un bouton déroulant pour regrouper les commandes Exécuter et Déboguer dans un emplacement central (et compact) dans la zone de titre de l'éditeur (Visual Studio Code version 1.54). Sur la base des commentaires des utilisateurs, elle a essayé d'améliorer le bouton déroulant en mémorisant la dernière action exécutée. Le bouton déroulant a maintenant deux zones de clic, une pour l'action par défaut (à gauche) et une autre pour la liste déroulante (à droite) qui, lorsqu'elle est sélectionnée, exécute l'action et la mémorise comme la nouvelle valeur par défaut.
Le comportement de la liste déroulante*:
- S'il n'y a qu'une seule action Exécuter ou Déboguer, le menu déroulant est omis.
- S'il y a plus d'une action Exécuter ou Déboguer, toutes les actions apparaissent dans le menu déroulant et l'action par défaut est définie sur la première action du menu déroulant (tant qu'il n'y a pas d'action mémorisée).
- L'action par défaut est conservée pour un espace de travail spécifique lors des redémarrages de VS Code*; il n'est pas conservé par éditeur.
TypeScript 4.4
Cette version inclut la prise en charge de la prochaine version TypeScript 4.4.
Quelques points forts de l'outillage :
- Incrustation de conseils pour les noms et les types de paramètres dans les fichiers JavaScript et TypeScript.
- Suggestions d'orthographe de base dans des fichiers JavaScript simples. Ceux-ci ne sont affichés que si le service de langage TypeScript est confiant dans l'erreur et dans le correctif.
Pour commencer à utiliser les builds Nightly 4.4, installez l'extension TypeScript Nightly.
Quelques éléments qui vont accompagner TypeScipt 4.4
Analyse du flux de contrôle des conditions d'alias :
En JavaScript, nous devons souvent sonder une variable de différentes manières pour voir si elle a un type plus spécifique que nous pouvons utiliser. TypeScript comprend ces vérifications et les appelle des gardes de type. Au lieu d'avoir à convaincre TypeScript du type d'une variable chaque fois que nous l'utilisons, le vérificateur de type s'appuie sur ce qu'on appelle l'analyse de flux de contrôle pour déduire le type dans chaque construction de langage.
Par exemple, nous pouvons écrire quelque chose comme :
| Code TypeScript : | Sélectionner tout |
1 2 3 4 5 6 | function foo(arg: unknown) { if (typeof arg === "string") { // We know this is a string now. console.log(arg.toUpperCase()); } } |
Dans cet exemple, nous avons vérifié si arg était un string. TypeScript a reconnu la vérification de typeof arg === "string", qu'il considérait comme une protection de type, et a pu déterminer que arg devrait être un string dans le corps du bloc if.
Cependant, que se passe-t-il si nous déplaçons la condition vers une constante ?
| Code TypeScript : | Sélectionner tout |
1 2 3 4 5 6 7 8 | function foo(arg: unknown) { const argIsString = typeof arg === "string"; if (argIsString) { console.log(arg.toUpperCase()); // ~~~~~~~~~~~ // Error! Property 'toUpperCase' does not exist on type 'unknown'. } } |
Dans les versions précédentes de TypeScript, cela aurait conduit à une erreur – même si argIsString avait reçu la valeur garde de type, TypeScript perdait simplement cette information. C'est dommage, car nous pourrions vouloir réutiliser la même vérification à plusieurs endroits. Pour contourner ce problème, les utilisateurs doivent souvent se répéter ou utiliser des assertions de type (casts).
Dans TypeScript 4.4, ce n'est plus le cas. L'exemple ci-dessus fonctionne sans erreur ! Lorsque TypeScript voit que nous testons une valeur constante, il effectuera un peu de travail supplémentaire pour voir s'il contient une protection de type. Si cette protection de type opère sur un const, une propriété readonly ou un paramètre non modifié, alors TypeScript est capable de restreindre cette valeur de manière appropriée.
Différentes sortes de conditions de garde de type sont préservées – pas seulement des vérifications typeof. Par exemple, les contrôles sur les syndicats discriminés fonctionnent comme un charme.
| Code TypeScript : | Sélectionner tout |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 | type Shape = | { kind: "circle", radius: number } | { kind: "square", sideLength: number }; function area(shape: Shape): number { const isCircle = shape.kind === "circle"; if (isCircle) { // We know we have a circle here! return Math.PI * shape.radius ** 2; } else { // We know we're left with a square here! return shape.sideLength ** 2; } } |
Comme autre exemple, voici une fonction qui vérifie si deux de ses entrées ont un contenu.
| Code TypeScript : | Sélectionner tout |
1 2 3 4 5 6 7 8 9 10 11 12 13 | function doSomeChecks( inputA: string | undefined, inputB: string | undefined, shouldDoExtraWork: boolean, ) { let mustDoWork = inputA && inputB && shouldDoExtraWork; if (mustDoWork) { // Can access 'string' properties on both 'inputA' and 'inputB'! const upperA = inputA.toUpperCase(); const upperB = inputB.toUpperCase(); // ... } } |
TypeScript peut comprendre que inputA et inputB sont tous deux présents si mustDoWork est true. Cela signifie que nous n'avons pas à écrire une assertion non nulle comme inputA! pour convaincre TypeScript que inputA est undefined.
Une caractéristique intéressante ici est que cette analyse fonctionne de manière transitive. Si nous avons une constante affectée à une condition qui contient plus de constantes et que ces constantes sont chacune affectées à des gardes de type, alors TypeScript peut propager les conditions plus tard.
| Code TypeScript : | Sélectionner tout |
1 2 3 4 5 6 7 8 9 10 11 | function f(x: string | number | boolean) { const isString = typeof x === "string"; const isNumber = typeof x === "number"; const isStringOrNumber = isString || isNumber; if (isStringOrNumber) { x; // Type of 'x' is 'string | number'. } else { x; // Type of 'x' is 'boolean'. } } |
Notez qu'il y a une limite - TypeScript ne va pas arbitrairement en profondeur lors de la vérification de ces conditions, mais son analyse est suffisamment approfondie pour la plupart des vérifications.
Par défaut, le type unknown dans les variables de capture (--useUnknownInCatchVariables) :
En JavaScript, tout type de valeur peut être lancé avec throw et capturé dans une clause catch. Pour cette raison, TypeScript a historiquement typé les variables de clause catch comme any et n'autorisait aucune autre annotation de type*:
| Code TypeScript : | Sélectionner tout |
1 2 3 4 5 6 7 8 | try { // Who knows what this might throw... executeSomeThirdPartyCode(); } catch (err) { // err: any console.error(err.message); // Allowed, because 'any' err.thisWillProbablyFail(); // Allowed, because 'any' :( } |
Une fois que TypeScript a ajouté le type unknown, il est devenu clair qu'unknown était un meilleur choix que any dans la clause catch pour les utilisateurs qui souhaitent le plus haut degré d'exactitude et de sécurité de type, car il se rétrécit mieux et nous oblige à tester par rapport à des valeurs arbitraires. Finalement, TypeScript 4.0 a permis aux utilisateurs de spécifier une annotation de type explicite [C]unknown[/] (ou catch) sur chaque variable de clause catch afin que nous puissions opter pour des types plus stricts au cas par cas*; cependant, pour certains, spécifier manuellement : unknown sur chaque clause catch était une corvée.
C'est pourquoi TypeScript 4.4 introduit un nouvel indicateur appelé --useUnknownInCatchVariables. Cet indicateur modifie le type par défaut des variables de clause catch de any à unknown.
| Code TypeScript : | Sélectionner tout |
1 2 3 4 5 6 7 8 9 10 11 12 13 | try { executeSomeThirdPartyCode(); } catch (err) { // err: unknown // Error! Property 'message' does not exist on type 'unknown'. console.error(err.message); // Works! We can narrow 'err' from 'unknown' to 'Error'. if (err instanceof Error) { console.error(err.message); } } |
Source : Visual Studio Code
