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 du générateur, l’obsolescence des chemins de projet dans TestInfo, des améliorations de la nouvelle interface utilisateur et de nombreuses mises à jour de la plateforme.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, JetBrains introduit la configuration de l'ensemble 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, JetBrains a 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), JetBrains a 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’EDI. La nouvelle implémentation facilite également les extensions et les modifications.
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é
JetBrains a 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é que sur la première position et il n'est pas possible de modifier la valeur. Seules les modifications fournies par les menus de transformation ci-joints 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.
Forks conditionnels 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’EDI, 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 son effort pour séparer le chargement des classes de l'accès au modèle et l’obsolescence de ReloadableSModule, JetBrains a modifié le fonctionnement du chargement des classes pour les modules. Bien que l'éditeur de logiciels pour développeurs ait travaillé 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.
Nouveautés de la plateforme
Nouveau terminal dans la nouvelle interface utilisateur (Bêta)
MPS 2024.1 propose un terminal entièrement retravaillé, 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.
Possibilité de réduire l'échelle de l'EDI entier
Vous pouvez maintenant zoomer et dézoomer sur l'interface, avec la possibilité de réduire l’échelle de l’EDI à 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'EDI 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'EDI é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
JetBrains a 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'EDI 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. JetBrains a é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
Lors de la publication de chaque nouvelle version majeure, JetBrains prépare des instructions pour la migration à partir de versions plus ancienne de MPS pour s'assurer que tout fonctionne correctement. JetBrains vous invite à les examiner attentivement.
Nouveautés et téléchargement de MPS 2024.1