IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Visual Studio Code 1.59 est disponible. Cette version s'accompagne d'une amélioration de la vue Extensions
Ainsi que du suivi des processus enfants et des avertissements de fermeture

Le , par Stéphane le calme

40PARTAGES

9  0 
Planche de travail

Extensions

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

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de Stéphane le calme
Chroniqueur Actualités https://www.developpez.com
Le 06/09/2021 à 11:01
Visual Studio Code 1.60 est disponible et apporte la détection automatique du langage,
ainsi que la possibilité de garder les éditeurs de terminal ouverts au lieu de les fermer lorsqu'ils ne parviennent pas à être restaurés

Planche de travail

Détection automatique du langage

Dans l'avant dernière version, Microsoft a introduit une fonctionnalité expérimentale pour les fichiers sans titre qui définirait automatiquement le mode de langage du fichier en fonction du contenu. La fonction de détection automatique du langage utilise l'apprentissage automatique pour deviner le langage et le modèle d'apprentissage automatique s'exécute entièrement en local sur votre machine. Le modèle est alimenté par la bibliothèque ML open source, Tensorflow.js.

Dans cette version, Microsoft active la détection automatique du langage par défaut et étend également la détection pour inclure les fichiers qui n'ont pas d'extension de fichier. Dans Notebooks, Microsoft propose un moyen simple de demander la détection du langage à l'aide du sélecteur de langage.

Et Microsoft d'expliquer :

« Nous avons ajouté cette fonctionnalité car nous avons constaté que certains nouveaux utilisateurs de VS Code ne savaient pas comment définir le mode de langage et ne savaient pas que cela était nécessaire pour obtenir le riche ensemble de fonctionnalités de VS Code (colorisation du langage et recommandations d'extension). Permettre aux nouveaux utilisateurs de voir rapidement les fonctionnalités de langage et les extensions disponibles pour VS Code les aide à se lancer dans l'éditeur.

« De plus, les utilisateurs expérimentés qui utilisent des éditeurs de texte sans titre comme bloc-notes n'ont plus besoin de définir explicitement le mode de langage, ce qui, nous l'espérons, rationalisera leur flux de travail ».

Vous trouverez ci-dessous plusieurs scénarios amusants activés par la détection automatique du langage.

Prenez un exemple en ligne et collez-le dans un éditeur sans titre*:


Option de détection automatique dans le sélecteur de langage Notebooks*:


Boîte de dialogue de confirmation de l'éditeur de terminal

La boîte de dialogue présentée lors de la fermeture d'un éditeur de terminal avec des processus enfants en cours d'exécution est désormais spécifique à l'éditeur de terminal et n'offrira plus de moyen d'effectuer l'action « Enregistrer » le terminal.


Gardez les éditeurs ouverts au lieu de les fermer lorsqu'ils ne parviennent pas à être restaurés

Auparavant, lorsqu'un éditeur ne parvenait pas à être restauré après le rechargement de la fenêtre ou le redémarrage de l'application, l'éditeur se fermait automatiquement jusqu'à ce qu'un éditeur se chargeant avec succès soit trouvé. Ce comportement a conduit à des résultats frustrants, où une mise en page d'éditeur soigneusement créée disparaîtrait en raison de la fermeture des éditeurs.

Avec cette version, un éditeur qui a déjà été ouvert avec succès ne se fermera pas, même s'il ne parvient pas à se restaurer. L'éditeur signale le problème et propose de retenter l'opération.

Ouvrir l'éditeur de paramètres sur le côté

Il est désormais possible d'ouvrir l'éditeur de paramètres dans un groupe latéral en configurant un raccourci clavier à l'aide de l'argument openToSide.

Code : Sélectionner tout
1
2
3
4
5
6
7
{
  "key": "cmd+,",
  "command": "workbench.action.openSettings",
  "args": {
    "openToSide": true
  }
}
Cela fonctionne également avec la commande workbench.action.openSettingsJson.

Éditeur

Colorisation des paires de crochets haute performance

L'éditeur prend désormais en charge la colorisation native des paires de crochets.


La colorisation des paires de crochets peut être activée en définissant editor.bracketPairColorization.enabled sur true. Toutes les couleurs sont thématiques et jusqu'à six couleurs peuvent être configurées.

Suggestions en ligne dans la saisie semi-automatique

Les suggestions intégrées peuvent désormais étendre l'aperçu des suggestions lorsque le widget de saisie semi-automatique est affiché. Si une suggestion sélectionnée dans le widget de saisie semi-automatique peut être étendue par un fournisseur de saisie semi-automatique, l'extension est affichée en italique. Appuyer une fois sur Tab n'acceptera toujours que la suggestion de saisie semi-automatique. Appuyez une deuxième fois sur Tab pour accepter la suggestion en ligne.

Cette fonctionnalité nécessite l'activation de l'aperçu de suggestion ("editor.suggest.preview": true).

Terminal

Rendu personnalisé de box drawing et block element characters

Box drawing et block element characters utilisent désormais des glyphes personnalisés au pixel près au lieu d'utiliser la police lorsque l'accélération GPU est activée (terminal.integrated.gpuAcceleration). Cela signifie, par exemple, que les cases sont dessinées sans espaces, même si vous définissez la hauteur des lignes ou l'espacement des lettres dans le terminal.


Reconnexion plus rapide après rechargement de la fenêtre

Auparavant, lors du rechargement d'une fenêtre, l'analyse de l'état du tampon d'un terminal pouvait prendre jusqu'à 300 ms et il y avait également une possibilité de corruption. Pour plusieurs terminaux occupés, cela peut vite s'additionner ! Pour résoudre ce problème, la méthode de restauration du tampon est passée de l'enregistrement d'un grand nombre d'événements de terminal bruts récents sur l'hôte pty au maintien d'une interface de terminal sans tête sur l'hôte pty et à l'écriture de toutes les données dessus.

Cette approche apporte plusieurs avantages :
  • La quantité de défilement à restaurer peut être affinée. La valeur par défaut est maintenant 100, ce qui est un bon équilibre entre la vitesse et la quantité de données. La quantité de défilement peut être modifiée avec le paramètre terminal.integrated.persistentSessionScrollback.
  • Grâce à l'analyseur rapide de xterm.js, cela devrait avoir un impact minimal sur l'utilisation du processeur et réduire l'utilisation globale de la mémoire sur l'hôte pty.
  • Les modes de terminal sont maintenant restaurés explicitement, ce qui pourrait potentiellement être manqué auparavant et provoquer une corruption de la mémoire tampon.
  • Il n'est plus nécessaire de rejouer des événements de redimensionnement coûteux car le tampon du terminal est toujours synchronisé avec sa taille.
  • Comme la restauration est relativement rapide, tout est géré dans une seule image. Cela signifie que le temps CPU précieux n'est pas gaspillé pour rendre le terminal partiellement restauré et ralentir davantage les choses.

L'accélération de cette nouvelle implémentation dépend de nombreux facteurs, tels que le nombre de terminaux, le matériel, la taille de la mémoire tampon du terminal et ce qui se passait dans le terminal. Une estimation approximative de la restauration d'un tampon de terminal complet devrait donner une accélération approximative de 5 à 10x.

Source : Visual Studio Code
0  0