Nouveautés de MPS 2024.1

MPS 2024.1 apporte une nouvelle implémentation asynchrone du volet Logical View dans la fenêtre d'outil Project, des améliorations substantielles de la prise en charge de Kotlin pour plusieurs plateformes et une accélération sensible de l'exécution des tests. Vous y trouverez également des forks conditionnels dans les plans de génération, l'obsolescence des chemins de projet dans TestInfo, des améliorations de la nouvelle interface utilisateur et de nombreuses mises à jour de la plateforme.

Consultez la liste détaillée des améliorations ci-dessous.

Prise en charge améliorée de Kotlin par la plateforme

La prise en charge de Kotlin dans MPS était initialement conçue pour prendre en charge le code commun uniquement. Mais le seul cas d'utilisation possible dans MPS était la compilation sur la JVM, et la distinction entre le code commun et le code JVM n'était pas claire.

Dans cette version, nous introduisons la configuration des ensembles de sources de la plateforme pour les nœuds Kotlin. Cela vous permet d'identifier les plateformes cibles prises en charge par un morceau de code et de masquer les déclarations du code incompatible.

Ensembles de sources

Dans un projet Kotlin standard, vous pouvez utiliser des ensembles de sources pour séparer le code ciblant différentes plateformes. Dans MPS, nous avons introduit cela au niveau racine, avec la possibilité de spécifier l'ensemble des plateformes prises en charge pour chaque nœud racine Kotlin. Vous pouvez configurer ces ensembles de sources au niveau du nœud racine à l'aide d'une action d'intention.

En voici les implications pratiques :

  • Le code sous un ensemble de sources donné ne peut accéder qu'aux déclarations avec des plateformes compatibles. Par exemple, le code spécifique à la JVM peut accéder uniquement au code spécifique à la JVM et au code commun qui cible la JVM.
  • Les sources générées sont structurées dans des répertoires spécifiques à l'ensemble de sources. Si un répertoire n'est pas spécifié, il utilise l'ensemble de sources par défaut, qui correspond à la valeur par défaut du module.
  • Les déclarations expect et actual sont désormais prises en charge.

Par défaut, le code Kotlin sans plateforme explicite utilise la JVM, afin de maintenir la rétrocompatibilité.

Chargement et compilation des stubs

Les stubs ont été améliorés pour prendre en charge de nouveaux cas d'utilisation multiplateformes. Dans le passé, MPS proposait des options distinctes pour les stubs Kotlin et Kotlin/JVM, qui chargeaient respectivement les stubs communs et JVM.

Ces deux options ont désormais été unifiées dans celle des stubs Kotlin, qui détermine désormais automatiquement si un artefact fourni expose du code commun, du code JVM ou du code pour d'autres plateformes.

Comme les déclarations entre les bibliothèques communes et spécifiques à la plateforme sont redondantes (puisque les deux artefacts contiennent toutes les déclarations nécessaires), nous avons introduit un nouveau mécanisme de filtrage des doublons pour que les stubs restent en ordre. Lorsque des bibliothèques spécifiques à une plateforme sont déclarées sous le même module, elles peuvent accéder aux déclarations communes, vous n'avez donc pas besoin de les déclarer à nouveau.

La configuration des dépendances est la même que précédemment :

  • Les bibliothèques communes et spécifiques à la plateforme peuvent être utilisées comme stubs.
  • Les bibliothèques JVM sont nécessaires pour compiler le code commun sur la JVM et doivent être déclarées dans la facette Java.

Par exemple, l'écriture de code commun nécessite d'utiliser une bibliothèque commune pour les stubs, via l'ensemble de sources commun, mais vous devez également déclarer l'artefact Java dans la facette Java.

Lisibilité Kotlin améliorée sans le système de types CodeRules

Le code Kotlin dans MPS générait de nombreuses erreurs de typesystem et de portée lorsque le plugin Kotlin Typesystem, basé sur CodeRules, n'était pas disponible. Afin d'améliorer la lisibilité et la testabilité, ces vérifications et erreurs sont désormais désactivées lorsque le plugin du système de types basé sur CodeRules n'est pas disponible.

Dans de tels cas, toutes les portées des langages Kotlin sont remplacées par une portée par défaut incluant tous les nœuds des concepts compatibles. Cela supprime toutes les erreurs de faux positifs, car tous les nœuds valides sont dans la portée.

Les directives pour gérer le code Kotlin restent les mêmes qu'auparavant :

  • Pour l'écriture et la vérification du code Kotlin, CodeRules doit être activé et le plugin Kotlin Typesystem doit être installé.
  • La lecture de Kotlin et sa génération peuvent s'effectuer en toute sécurité sans eux.

Réimplémentation du volet Logical View

Le volet Logical View s'appuie désormais sur une architecture asynchrone, ce qui permet de maintenir la réactivité de l'interface utilisateur et améliore les performances globales de l'IDE. La nouvelle implémentation facilite également les extensions et les modifications. Pour en savoir plus, reportez-vous à notre article intitulé ProjectPane implementation on top of ProjectViewTree (Implémentation de ProjectPane par-dessus ProjectViewTree) dans la base de connaissances.

Cette nouvelle implémentation a entraîné quelques changements notables :

  • Les indicateurs d'erreur et d'avertissement ne sont plus disponibles.
  • Les erreurs et les avertissements trouvés dans la hiérarchie sont soulignés en rouge.
  • L'option Show Descriptor Models affecte tous les modèles de descripteur.
  • Certaines opérations de glisser-déposer fonctionnent différemment.
  • Les paramètres du volet Logical View ont été légèrement réorganisés.

Cellules d'espace réservé

Nous avons introduit un nouveau style dans BaseLanguage qui permet aux cellules constantes de servir d'espaces réservés s'il manque une valeur (un nœud enfant ou une référence). Par exemple, si une classe ne comporte aucun constructeur, une cellule d'espace réservé <no default constructor> peut être affichée à la place. Le style amène les cellules constantes à présenter le comportement que vous attendez de ces cellules d'espace réservé. Le curseur ne peut être placé qu'à la première position et il n'est pas possible de modifier la valeur. Seules les modifications fournies par les menus de transformation associés sont autorisées.

Modifications apportées au langage de build

L'option booléenne doNotCompile des modules dans le langage de build a été remplacée par une énumération Java pour mieux distinguer les cas où :

  • Le module ne contient aucun code.
  • Le module contient du code, mais le code est compilé par des outils autres que MPS.

Ces deux cas étaient représentés par la valeur true.

La nouvelle enum Java a trois valeurs possibles :

  • compile in MPS
  • compile externally
  • no code

Lors de la migration vers la version 2024.1, la valeur false d'origine de doNotCompile sera migrée vers compile in MPS, tandis que la valeur true de doNotCompile sera migrée vers compile externally.

Fourches conditionnelles dans les plans de génération

Une nouvelle petite fonctionnalité expérimentale vous permet d'ajouter un fork pour un plan de génération sans réellement modifier le plan d'origine forké. Vous pouvez indiquer qu'un plan de génération est forké à partir d'un autre plan de génération. Le plan que vous aurez signalé sera traité comme s'il était mentionné explicitement, avec l'instruction standard fork insérée au tout début du plan de génération forké.

De plus, lors de la définition d'un fork, vous pouvez utiliser un modificateur de chaîne qui servira de déclencheur. Le fork ne se produira que si le modèle généré appartient à un module dont la facette cible de génération possède un identifiant de facette correspondant au déclencheur de chaîne.

Rapports XML JUnit5 dans MPS

Les tests JUnit dans MPS peuvent désormais générer des rapports de test non seulement aux formats Vintage et Jupiter, mais également au format Open Test Reporting. Une nouvelle option est disponible dans les options de test du langage de build pour contrôler si le rapport Open Test est inclus dans les rapports générés. Si l'option est définie sur true, des fichiers de rapport, nommés junit-platform-events*-$BUILD_NAME$.xml, sont créés dans le répertoire du projet.

Si l'option est définie sur false, ce sont les anciens rapports pour les moteurs Vintage et Jupiter qui sont créés.

Annotation JUnit5 @DisplayName propagée aux rapports de test

Les rapports de test MPS respectent désormais l'annotation JUnit @DisplayName et propagent le nom aux rapports affichés dans la fenêtre d'outil du rapport de test.

Améliorations de l'exécution des tests

Lors de l'exécution d'un test de nœud ou d'éditeur, MPS copiait l'intégralité du modèle de test dans des modèles transitoires et effectuait des copies supplémentaires de chaque nœud de cas de test (en commençant par la racine NodeTestCase ou EditorTestCase). Pour les grands modèles de test, cela avait tendance à impacter notablement les performances. Cela aboutissait également à une configuration plutôt étrange avec des nœuds de test dupliqués. Dans MPS 2024.1, les modèles avec tests ne seront plus copiés ; seuls les enfants TestNode de NodeTestCase ou EditorTestCase le seront, ainsi que leurs nœuds d'environnement respectifs (les cibles de leurs références).

Le chemin du projet n'est plus nécessaire dans TestInfo

Les déclarations TestInfo ne sont plus requises pour les tests qui nécessitent l'ouverture d'un projet MPS. Cela s'applique à toutes les approches d'exécution des tests JUnit :

  • Si le test est exécuté depuis l'IDE, en cours de processus ou hors processus, le projet actuellement ouvert sera utilisé.
  • Si le test est exécuté avec la tâche <launchtests>, vous pouvez spécifier le project path comme option supplémentaire pour le chemin de projet de la tâche. S'il n'est pas spécifié, ${basedir} est utilisé, ce qui correspond au répertoire d'accueil du projet en cours.
  • Pour les cas particuliers où vous ne pouvez utiliser aucune des approches ci-dessus, vous pouvez spécifier l'emplacement du projet à l'aide de la propriété système -Dmps.test.project.path.

Les déclarations TestInfo existantes sont toujours prises en charge et peuvent être conservées.

Refonte complète du chargement des classes de modules

Dans le cadre de notre effort pour séparer le chargement des classes de l'accès au modèle et l'obsolescence de ReloadableSModule, nous avons modifié le fonctionnement du chargement des classes pour les modules. Bien que nous ayons travaillé dur pour éviter toute perturbation aux utilisateurs finaux, les mises à jour peuvent entraîner des problèmes de chargement des classes qui n'existaient pas auparavant.

Dans le cadre de cette refonte, MPS s'en tient désormais aux dépendances déclarées dans module.xml pour les modules déployés, sans essayer de les calculer au démarrage en fonction des informations dispersées dans les fichiers du module. Lors de la phase de conception, les dépendances sont dérivées des informations collectées lors de la phase de transformation du modèle, et elles ne sont pas non plus recalculées ici. L'ancienne logique qui analyse les dépendances des modules à partir des fichiers .mpl ou .msd reste en place comme solution de repli en cas d'échec de la nouvelle méthode.

Ces changements s'inscrivent dans le cadre d'un effort continu d'amélioration des facettes des modules Java et des facettes des modules en général.

Exclure les nœuds en commentaires des portées (également disponible dans 2022.3.2)

Lorsque vous utilisez le calcul de portée par défaut, les nœuds cibles potentiels figurant dans les commentaires sont désormais automatiquement exclus de la portée.

Autre

  • Un littéral long hexadécimal a été introduit dans BaseLanguage.
  • Lorsqu'un projet nécessite une migration et qu'il existe des incompatibilités entre la version du modèle et du module (par exemple, si le module mentionne une version de langage différente de celle mentionnée dans un modèle), une fenêtre de notification contextuelle s'affiche avec une action répertoriant tous les modules présentant des incompatibilités. C'est intéressant lorsque vous fusionnez du code migré, car vous pouvez vous assurer que l'état fusionné reflète les bons langage et versions de module.
  • Les modules sous un devkit dans le volet Logical View s'affichent en tant que nœuds module-reference. Cela ressemble à la présentation des modules d'exécution sous un module de langage.

Nombreux correctifs de bugs

  • Comme d'habitude, ce build corrige son lot de bugs. Vous trouverez ici la liste complète de tous les problèmes que nous avons résolus.

Nouveautés de la plateforme

Nouveau terminal dans la nouvelle interface utilisateur

Bêta

MPS 2024.1 propose un terminal entièrement remanié, avec des améliorations visuelles et fonctionnelles qui simplifient les tâches en ligne de commande. Cette mise à jour apporte une nouvelle apparence à cet outil familier, avec des commandes séparées en blocs distincts, ainsi qu'un ensemble de fonctionnalités étendu, notamment une navigation fluide entre les blocs, la complétion pour les commandes et un accès facile à l'historique des commandes. Pour en savoir plus, consultez cet article de blog.

Possibilité de réduire l'échelle de l'IDE entier

Vous pouvez maintenant zoomer et dézoomer sur l'interface, avec la possibilité de réduire l’échelle de l’IDE à 90 %, 80 % ou 70 %.

Changement de prise en charge des versions Gradle

À partir de cette version, MPS ne prend plus en charge les projets utilisant des versions de Gradle antérieures à 4.5 et l'IDE n'effectuera pas de synchronisation Gradle pour les projets comportant des versions de Gradle non prises en charge.

Nombreuses fonctionnalités VCS

Option permettant de réviser les modifications de la branche dans un onglet Log

MPS 2024.1 simplifie le workflow de révision du code en proposant une vue ciblée des modifications liées aux branches. Pour GitHub, GitLab et Space, il est désormais possible d'afficher les modifications d'une branche donnée dans un onglet Log séparé de la fenêtre d'outil Git. en cliquant sur le nom de la branche dans la fenêtre d'outils Pull Requests et en sélectionnant Show in Git Log dans le menu.

Prise en charge des réactions aux commentaires de révision du code

MPS 2024.1 prend en charge les réactions aux commentaires de révision pour les requêtes d'extraction GitHub et les requêtes de fusion GitLab, avec un ensemble d'émoticônes déjà disponibles.

Création de requêtes d'extraction/fusion à partir de notifications push

Après un push de vos modifications vers le système de contrôle de version, l'IDE émet désormais une notification vous informant de la réussite de l'opération et vous suggérant une action pour créer une requête d'extraction/de fusion.

Indicateurs visuels pour les mises à jour GitHub en attente

Nous avons introduit des indicateurs visuels pour vous informer sur les mises à jour en attente dans votre workflow de révision du code. Lorsque des modifications requièrent votre attention, un point s'affiche sur l'icône de la fenêtre d'outil. Les requêtes d'extraction non vues seront également signalées par un point bleu, ce qui vous garantit de ne pas manquer des mises à jour dans votre processus de révision du code.

Prévention de l'envoi de commits de fichiers volumineux vers les référentiels

Pour vous aider à éviter les rejets du contrôle de version dus à des fichiers trop volumineux, l'IDE inclut désormais une vérification avant commit qui vous empêche de valider ces fichiers et vous informe de la restriction.

Filtre de branche pour l'onglet History de la fenêtre d'outil Git

Dans la fenêtre d'outil Git, le bouton Show all branches a été remplacé par un filtre de branche, ce qui vous permet d'examiner les modifications apportées à un fichier dans une branche donnée. Nous avons également modifié l'orientation de la barre d'outils, qui est maintenant positionnée à l'horizontale, pour une plus grande facilité d'utilisation.

Amélioration de la recherche dans la fenêtre contextuelle Branches

Dans la fenêtre contextuelle Branches, vous pouvez désormais filtrer les résultats de recherche par actions et par référentiels pour naviguer plus rapidement et plus précisément dans votre système de contrôle de version.

Option de fusion Allow unrelated histories

La boîte de dialogue Merge into comporte désormais une option Allow unrelated histories dans son menu déroulant. Lorsque cette option est sélectionnée, vous pouvez fusionner deux branches qui n'ont pas d'historique commun.

Option permettant d'exclure des dossiers et des fichiers de la comparaison

Dans le visualiseur de diff, vous pouvez à présent spécifier les dossiers et les fichiers à ignorer pendant le processus de comparaison afin de vous concentrer uniquement sur les modifications pertinentes. Il vous suffit de cliquer droit sur un fichier ou un dossier que vous ne souhaitez pas voir dans les résultats de comparaison et de sélectionner Exclude from results dans le menu contextuel.

Guide de migration

Pour chaque nouvelle version majeure de MPS, nous fournissons des instructions pour vous aider à effectuer la migration dans les meilleures conditions. Veuillez les examiner attentivement dans le Guide de la migration actualisé.