{"id":34309,"date":"2020-06-11T13:56:50","date_gmt":"2020-06-11T12:56:50","guid":{"rendered":"https:\/\/blog.jetbrains.com\/fr\/?p=801"},"modified":"2020-06-12T08:19:32","modified_gmt":"2020-06-12T07:19:32","slug":"publication-de-kotlin-1-4-m2","status":"publish","type":"post","link":"https:\/\/blog.jetbrains.com\/fr\/2020\/06\/11\/publication-de-kotlin-1-4-m2\/","title":{"rendered":"Publication de Kotlin 1.4-M2"},"content":{"rendered":"Le temps passe vite et nous vous pr\u00e9sentons d\u00e9j\u00e0 en avant-premi\u00e8re plusieurs nouvelles fonctionnalit\u00e9s particuli\u00e8rement puissantes de Kotlin 1.4. D\u00e9couvrez ce que Kotlin 1.4-M2 vous r\u00e9serve, essayez-la et profitez de ses fonctionnalit\u00e9s avant le lancement officiel de Kotlin 1.4.\r\n\r\n\r\n\r\nNous remercions tous ceux qui ont essay\u00e9 notre premi\u00e8re version preview de Kotlin 1.4, nous ont fait part de leurs commentaires et contribu\u00e9 \u00e0 am\u00e9liorer Kotlin !\r\n\r\nUn grand merci \u00e9galement \u00e0 ceux qui ont d\u00e9j\u00e0 test\u00e9 les am\u00e9liorations de la biblioth\u00e8que standard de Kotlin 1.4-M2 annonc\u00e9es dans notre pr\u00e9c\u00e9dent article de blog.\r\n\r\nDans cet article, nous pr\u00e9sentons les nouvelles fonctionnalit\u00e9s et principales am\u00e9liorations apport\u00e9es par la version 1.4-M2\u00a0:\r\n\r\n\tLa prise en charge du partage de code dans plusieurs cibles gr\u00e2ce \u00e0 la structure hi\u00e9rarchique dans les projets multiplateformes.\r\n\tUn nouvel assistant de projet Kotlin flexible pour cr\u00e9er et configurer facilement diff\u00e9rents types de projets.\r\n\tUn nouveau mode de compilation pour les auteurs de biblioth\u00e8ques, appel\u00e9 mode API explicite, qui permet de cr\u00e9er des API coh\u00e9rentes et bien d\u00e9crites.\r\n\tLa prise en charge par Kotlin\/Native de l'utilisation des fonctions de suspension de Swift et Objective-C.\r\n\tLe Gradle DSL de Kotlin\/JS amelior\u00e9, la prise en charge directe de CSS et une annotation d'exportation commune.\r\n\r\nVous trouverez la liste compl\u00e8te des\u00a0changements apport\u00e9s dans le journal des modifications.\r\n\r\nNous comptons sur vous pour essayer la preview et nous faire part de vos retours.\r\nPartager du code dans plusieurs cibles gr\u00e2ce \u00e0 la structure hi\u00e9rarchique du projet\r\nGr\u00e2ce \u00e0 la nouvelle structure hi\u00e9rarchique du projet, vous pouvez partager du code entre plusieurs cibles dans un projet multiplateforme.\r\n\r\nAuparavant, tout code ajout\u00e9 \u00e0 un projet multiplateforme pouvait \u00eatre plac\u00e9 soit dans un jeu de sources sp\u00e9cifique \u00e0 une plateforme, qui est limit\u00e9 \u00e0 une cible et ne peut \u00eatre r\u00e9utilis\u00e9 par aucune autre plateforme, soit dans un jeu de sources commun, tel que commonMain ou commonTest, qui est partag\u00e9 entre toutes les plateformes du projet. Dans le jeu de sources commun, vous ne pouviez appeler une API sp\u00e9cifique \u00e0 une plateforme qu'en utilisant une d\u00e9claration expect, qui n\u00e9cessite des impl\u00e9mentations actual sp\u00e9cifiques \u00e0 la plateforme.\r\n\r\nCela facilitait le partage de code entre toutes les cibles, mais il n'\u00e9tait pas si facile de le faire entre certaines cibles seulement, en particulier les cibles similaires qui pouvaient potentiellement r\u00e9utiliser une grande partie de la logique commune et des API tierces.\r\n\r\nPar exemple, dans un projet multiplateforme typique ciblant iOS, il y a deux cibles li\u00e9es \u00e0 iOS\u00a0: une pour les appareils iOS ARM64 et l'autre pour le simulateur x64. Ils ont des jeux de sources s\u00e9par\u00e9s, sp\u00e9cifiques \u00e0 la plateforme, mais en pratique, il est rarement n\u00e9cessaire d'avoir un code diff\u00e9rent pour l'appareil et le simulateur et leurs d\u00e9pendances sont tr\u00e8s similaires. Le code sp\u00e9cifique \u00e0 iOS pourrait donc \u00eatre partag\u00e9 entre eux.\r\n\r\nApparemment, dans cette configuration, il serait souhaitable d'avoir un jeu de sources partag\u00e9es pour deux cibles iOS, avec du code Kotlin\/Native qui pourrait toujours appeler directement n'importe laquelle des API communes pour l'appareil iOS et le simulateur.\r\n\r\n\r\n\r\nVous pouvez maintenant le faire gr\u00e2ce \u00e0 la prise en charge de la structure hi\u00e9rarchique du projet, qui d\u00e9duit et adapte les fonctionnalit\u00e9s de l'API et du langage disponibles dans chaque jeu de sources en fonction des cibles qui les utilisent.\r\nComment l'utiliser\r\nInstallez le plugin Kotlin 1.4 M2 incluant la prise en charge hi\u00e9rarchique du projet d\u00e8s maintenant\u00a0!\r\n\r\nAjoutez l'indicateur suivant au fichier gradle.properties de votre projet\u00a0:\r\nkotlin.mpp.enableGranularSourceSetsMetadata=true\r\n\r\nVeuillez noter que la structure hi\u00e9rarchique, ainsi que tous les projets multiplateformes, n\u00e9cessitent Gradle 6.0 ou une version ult\u00e9rieure \u00e0 compter de Kotlin 1.4-M2.\r\n\r\nVous pouvez cr\u00e9er une structure hi\u00e9rarchique avec des raccourcis de cible disponibles pour des sc\u00e9narios multicibles typiques ou manuellement en connectant les jeux de sources.\r\n\r\nPar exemple, cr\u00e9ez les deux cibles iOS et le jeu de sources partag\u00e9es pr\u00e9sent\u00e9 ci-dessus avec le raccourci ios()\u00a0:\r\nkotlin { ios() \/\/ iOS device and simulator\r\ntargets; iosMain and iosTest source sets}\r\n\r\nPour d'autres combinaisons de cibles, cr\u00e9ez une hi\u00e9rarchie manuellement en reliant les jeux de sources \u00e0 la relation dependOn.\r\n\r\n\r\nkotlin {\r\n\r\n   linuxX64()\r\n   mingwX64()\r\n   macosX64()\r\n\r\n   sourceSets {\r\n       ...\r\n\r\n       val desktopMain by creating {\r\n           dependsOn(commonMain)\r\n       }\r\n\r\n       val linuxX64Main by getting {\r\n           dependsOn(desktopMain)\r\n       }\r\n\r\n       val mingwX64Main by getting {\r\n           dependsOn(desktopMain)\r\n       }\r\n\r\n       val macosX64Main by getting {\r\n           dependsOn(desktopMain)\r\n       }\r\n   }\r\n}\r\n\r\nVous pouvez d\u00e9finir un jeu de sources partag\u00e9es pour les combinaisons de cibles suivantes\u00a0:\r\n\r\n\tJVM + JS + Native\r\n\tJVM + Native\r\n\tJS + Native\r\n\tJVM + JS\r\n\tNatifs\r\n\r\nPour l'instant, nous ne prenons pas en charge le partage d'un jeu de sources pour ces combinaisons\u00a0:\r\n\r\n\tMultiples cibles JVM\r\n\tCibles Android + JVM\r\n\tMultiples cibles JS\r\n\r\nN'h\u00e9sitez pas \u00e0 nous faire part de vos combinaisons de cibles par e-mail \u00e0 l'adresse feedback@kotlinlang.org. Cela nous permettra de prioriser les combinaisons les plus courantes.\r\nPartager du code dans les biblioth\u00e8ques\r\nGr\u00e2ce \u00e0 la structure hi\u00e9rarchique du projet, les biblioth\u00e8ques peuvent \u00e9galement fournir des API communes pour un sous-ensemble de cibles.\r\n\r\nLorsqu'une biblioth\u00e8que est publi\u00e9e, l'API de ses jeux de sources partag\u00e9s est int\u00e9gr\u00e9e aux artefacts de la biblioth\u00e8que, avec les informations sur la structure du projet. Lorsque vous utilisez cette biblioth\u00e8que, les jeux de sources partag\u00e9s de votre projet acc\u00e8dent pr\u00e9cis\u00e9ment aux API de la biblioth\u00e8que disponibles pour les cibles de chaque jeu de sources.\r\n\r\nPar exemple, consultez la hi\u00e9rarchie suivante des jeux de sources dans la branche native-mt du r\u00e9f\u00e9rentiel kotlinx.coroutines\u00a0:\r\n\r\n\r\n\r\nLe jeu de sources commun d\u00e9clare la fonction runBlocking et est compil\u00e9 pour la JVM et les cibles natives. Vous pouvez vous en servir et appeler runBlocking() \u00e0 partir d'un jeu de sources partag\u00e9 entre une cible JVM et des cibles natives, puisqu'il concorderait avec la \"signature des cibles\" du jeu de sources concurrent de la biblioth\u00e8que.\r\nSp\u00e9cifier les d\u00e9pendances une seule fois\r\nD\u00e9sormais, au lieu de sp\u00e9cifier des d\u00e9pendances sur diff\u00e9rentes variantes de la m\u00eame biblioth\u00e8que dans les jeux de sources partag\u00e9s et sp\u00e9cifiques \u00e0 la plateforme o\u00f9 elle est utilis\u00e9e, vous ne devez sp\u00e9cifier une d\u00e9pendance qu'une seule fois dans le jeu de sources partag\u00e9es.\r\nkotlin {\r\n  sourceSets {\r\n      val desktopMain by creating {\r\n          dependencies {\r\n               implementation(\"org.jetbrains.kotlinx:kotlinx-coroutines-core:1.3.7-1.4-M2\")\r\n          }\r\n      }\r\n  }\r\n}\r\n\r\nN'utilisez pas les noms d'artefacts de la biblioth\u00e8que kotlinx avec des suffixes sp\u00e9cifiant la plateforme, tels que -common, -native ou autre, car ils ne sont plus pris en charge. \u00c0 la place, utilisez le nom de l'artefact de base de la biblioth\u00e8que, qui dans l'exemple ci-dessus est kotlinx-coroutines-core. Cependant, le changement n'affecte pas actuellement les biblioth\u00e8ques stdlib et kotlin.test (stdlib-common et test-common)\u00a0; elles seront modifi\u00e9es ult\u00e9rieurement.\r\n\r\nSi vous avez besoin d'une d\u00e9pendance uniquement pour une plateforme sp\u00e9cifique, vous pouvez toujours utiliser des variantes sp\u00e9cifiques \u00e0 la plateforme des biblioth\u00e8ques standards et kotlinx avec des suffixes tels que -jvm ou -js, comme par exemple kotlinx-coroutines-core-jvm.\r\nTirer parti des biblioth\u00e8ques natives dans la structure hi\u00e9rarchique\r\nVous pouvez utiliser des biblioth\u00e8ques d\u00e9pendantes de la plateforme, telles que Foundation, UIKit et posix, dans des jeux de sources partag\u00e9s entre plusieurs cibles natives. Cela permet de partager davantage de code natif sans \u00eatre limit\u00e9 par des d\u00e9pendances sp\u00e9cifiques \u00e0 la plateforme.\r\n\r\nAucune \u00e9tape suppl\u00e9mentaire n'est n\u00e9cessaire, tout se fait automatiquement. IntelliJ IDEA vous aidera \u00e0 d\u00e9tecter les d\u00e9clarations communes que vous pouvez utiliser dans le code partag\u00e9.\r\n\r\nIl y a cependant certaines limites\u00a0:\r\n\r\n\tCette approche ne fonctionne que pour un jeu de sources natif qui est partag\u00e9 entre des jeux de sources sp\u00e9cifiques \u00e0 la plateforme. Cela ne fonctionne pas pour les jeux de sources natifs partag\u00e9s \u00e0 des niveaux plus \u00e9lev\u00e9s de la hi\u00e9rarchique du jeu de sources.\r\nPar exemple, si vous avez nativeDarwinMain qui est parent de watchosMain et iosMain, o\u00f9 iosMain a deux enfants \u2013 iosArm64Main et iosX64Main, vous pouvez utilisez des biblioth\u00e8ques d\u00e9pendantes de la plateforne pour iosMain seulement, mais pas pour nativeDarwinMain.\r\n\tCette approche ne fonctionne que pour les biblioth\u00e8ques interop\u00e9rables fournies avec Kotlin\/Native.\r\n\r\nEn savoir plus sur les d\u00e9tails techniques.\r\nComment l'utiliser\r\nPour permettre l'utilisation de biblioth\u00e8ques d\u00e9pendantes de la plateforme dans des jeux de sources partag\u00e9s, ajoutez ce qui suit \u00e0 votre gradle.properties\u00a0:\r\nkotlin.mpp.enableGranularSourceSetsMetadata=true\r\nkotlin.native.enableDependencyPropagation=false\r\n\r\nDonner votre avis sur la structure hi\u00e9rarchique\r\nLa structure hi\u00e9rarchique du projet est actuellement en phase de preview technologique et toujours en cours de d\u00e9veloppement. Vous pouvez consulter les probl\u00e8mes connus que nous allons r\u00e9soudre, dont certains ont des solutions provisoires.\r\n\r\nN'h\u00e9sitez pas \u00e0 demander de l'aide sur le canal \\#multiplateform Slack de Kotlin et \u00e0 signaler les bugs sur YouTrack, notre outil de suivi. Il s'agit d'une fonctionnalit\u00e9 complexe et importante, vos commentaires seront donc particuli\u00e8rement utiles\u00a0!\r\nGradle 6.0 ou ult\u00e9rieur requis dans les projets multiplateformes\r\n\u00c0 compter de Kotlin 1.4-M2, tous les projets multiplateformes n\u00e9cessitent Gradle 6.0 ou une version ult\u00e9rieure. Veuillez vous assurer de mettre \u00e0 jour Gradle pour vos projets utilisant le plugin kotlin-multiplatform.\r\nUn nouvel assistant de projet flexible\r\nGr\u00e2ce au nouvel assistant de projet Kotlin flexible, vous disposez d'un endroit unique o\u00f9 vous pouvez facilement cr\u00e9er et configurer des projets Kotlin de diff\u00e9rents types, y compris des projets multiplateformes, qui sont en g\u00e9n\u00e9ral assez difficiles \u00e0 configurer sans interface utilisateur.\r\n\r\n\r\n\r\nAuparavant, vous pouviez cr\u00e9er des projets Kotlin \u00e0 partir de diff\u00e9rents emplacements qui offraient plusieurs options de configuration. D\u00e9sormais, il n'y a plus qu'un seul emplacement pour le faire, alliant simplicit\u00e9 et flexibilit\u00e9\u00a0:\r\n\r\n\tS\u00e9lectionnez le mod\u00e8le de projet en fonction de ce que vous d\u00e9sirez faire.\r\n\tS\u00e9lectionnez le syst\u00e8me de build\u00a0: Gradle (Kotlin ou Groovy DSL), Maven ou IntelliJ. L'assistant ne propose que les syst\u00e8mes de build pris en charge pour le mod\u00e8le de projet s\u00e9lectionn\u00e9.\r\n\tPr\u00e9visualisez la structure du projet directement sur l'\u00e9cran principal.\r\n\r\nVous pouvez ensuite terminer la cr\u00e9ation de votre projet ou, \u00e9ventuellement, configurer le projet sur l'\u00e9cran suivant\u00a0:\r\n\r\n\tAjoutez ou supprimez des modules et des cibles pris en charge pour ce mod\u00e8le de projet.\r\n\tConfigurez les param\u00e8tres des modules et des cibles, par exemple, la version JVM cible, le mod\u00e8le cible et le framework de tests.\r\n\r\n\r\n\r\n\tD\u00e9finissez les d\u00e9pendances des modules entre\u00a0:\r\n\r\n\tmodules iOS et multiplateformes\r\n\tModules Android et multiplateformes\r\n\tModules JVM\r\n\r\n\r\n\r\n\r\n\r\n\u00c0 l'avenir, l'assistant de projet Kotlin sera encore plus adaptable gr\u00e2ce \u00e0 de nouvelles options de configuration et de nouveaux mod\u00e8les.\r\nComment l'utiliser\r\n\r\n\tInstallez le plugin Kotlin 1.4-M2.\r\n\tDans IntelliJ IDEA, cliquez sur File | New | Project.\r\n\tDans le panneau de gauche, s\u00e9lectionnez Kotlin (Experimental Wizard).\r\n\tCr\u00e9ez votre projet Kotlin.\r\n\r\nDes API coh\u00e9rentes et mieux d\u00e9crites avec un mode API explicite\r\nNous introduisons un nouveau mode de compilation pour aider les auteurs de biblioth\u00e8ques \u00e0 cr\u00e9er des API coh\u00e9rentes et bien d\u00e9crites. Dans ce mode API explicite, le compilateur effectue des v\u00e9rifications suppl\u00e9mentaires sur les d\u00e9clarations expos\u00e9es \u00e0 l'API publique de la biblioth\u00e8que\u00a0:\r\n\r\n\tDes modificateurs de visibilit\u00e9 sont n\u00e9cessaires pour les d\u00e9clarations si la visibilit\u00e9 par d\u00e9faut les expose \u00e0 l'API publique. Cela permet de s'assurer qu'aucune d\u00e9claration n'est expos\u00e9e publiquement de mani\u00e8re involontaire.\r\n\tDes sp\u00e9cifications de type explicites sont requises pour les propri\u00e9t\u00e9s et les fonctions qui sont expos\u00e9es \u00e0 l'API publique. Ainsi, les utilisateurs de l'API sont inform\u00e9s des types de membres de l'API qu'ils utilisent.\r\n\r\n\r\n\r\nSelon votre configuration, ces contr\u00f4les peuvent produire des erreurs (mode strict) ou des avertissements (mode warning).\r\n\r\nNous pr\u00e9voyons d'ajouter d'autres contr\u00f4les \u00e0 l'avenir afin d'am\u00e9liorer votre exp\u00e9rience d'auteur de biblioth\u00e8que. D\u00e9couvrez-en davantage \u00e0 ce sujet dans ce KEEP. Mais vous pouvez d\u00e9j\u00e0 essayer le mode API explicite et nous faire part de vos commentaires.\r\n\r\nPour compiler votre module en mode API explicite, ajoutez l'une des lignes suivantes \u00e0 votre script de build Gradle\u00a0:\r\nkotlin {   \r\n   explicitApi() \/\/ for strict mode\r\n   \/\/ or\r\n   explicitApiWarning() \/\/ for warning mode\r\n}\r\n\r\nDans Groovy, vous pouvez utiliser la syntaxe alternative ci-dessous\u00a0:\r\nkotlin {   \r\n   explicitApi = 'strict'\r\n   \/\/ or\r\n   explicitApi = 'warning'\r\n}\r\n\r\nLorsque vous utilisez le compilateur en ligne de commande, utilisez l'option du compilateur -Xexplicit-api, soit avec strict, soit avec warning\u00a0:\r\n-Xexplicit-api={strict|warning}\r\n\r\nPrise en charge par Kotlin\/Native de la suspension des fonctions et autres am\u00e9liorations\r\nDans cette preview, nous avons enfin ajout\u00e9 la prise en charge des fonctions de suspension de Kotlin pour Swift et Objective-C, qui ne couvre pour l'instant que les cas basiques. Nous continuons \u00e0 travailler pour vous donner toute la puissance des coroutines dans les applications Swift et Objective-C. Par ailleurs, nous sommes pr\u00eats \u00e0 pr\u00e9senter certains r\u00e9sultats de notre travail sur les performances et la stabilit\u00e9 de Kotlin\/Native.\r\nPrise en charge des fonctions de suspension de Kotlin pour Swift et Objective-C\r\nNous continuons \u00e0 d\u00e9velopper la prise en charge de l'utilisation des principales fonctionnalit\u00e9s de Kotlin depuis du code Swift et Objective-C. L'un des inconv\u00e9nients connus des versions pr\u00e9c\u00e9dentes \u00e9tait leur prise en charge incompl\u00e8te des coroutines Kotlin\u00a0: les fonctions de suspension n'\u00e9taient pas disponibles depuis du code Swift ou Objective-C.\r\n\r\nDans la preview M2, nous avons le plaisir de vous pr\u00e9senter la prise en charge basique des fonctions de suspension dans Swift et Objective-C. D\u00e9sormais, lorsque vous compilez un module Kotlin dans un framework Apple, les fonctions de suspension y sont disponibles comme des fonctions avec rappels (completionHandler dans la terminologie Swift\/Objective-C). Lorsque vous disposez de telles fonctions dans l'en-t\u00eate du framework g\u00e9n\u00e9r\u00e9, vous pouvez les appeler \u00e0 partir de votre code Swift ou Objective-C et m\u00eame les ignorer.\r\n\r\nPar exemple, si vous \u00e9crivez cette fonction Kotlin\u00a0:\r\nsuspend fun queryData(id: Int): String = ...\r\n\r\n\u2026alors vous pouvez l'appeler ainsi depuis Swift\u00a0:\r\nqueryData(id: 17) { result, error in\r\n   if let e = error {\r\n       print(\"ERROR: \\(e)\")\r\n   } else {\r\n       print(result!)\r\n   }\r\n}\r\n\r\nVeuillez noter que dans la preview M2 vous ne pouvez appeler la fonction de suspension que depuis le thread principal.\r\nEx\u00e9cuter du code Kotlin\/Native gr\u00e2ce \u00e0 l'ic\u00f4ne de goutti\u00e8re\r\nAuparavant, vous ne pouviez ex\u00e9cuter du code Kotlin\/Native que dans le Terminal ou en ex\u00e9cutant une t\u00e2che Gradle dans IntelliJ IDEA. Vous pouvez maintenant l'ex\u00e9cuter facilement gr\u00e2ce \u00e0 l'ic\u00f4ne de goutti\u00e8re, comme pour tout code Kotlin.\r\n\r\n\r\nAm\u00e9lioration des performances pour l'interop\u00e9rabilit\u00e9 C\r\nAfin d'am\u00e9liorer les performances de Kotlin\/Native, nous avons retravaill\u00e9 la mani\u00e8re dont les biblioth\u00e8ques C interop\u00e9rables sont construites. (Ces biblioth\u00e8ques sont des artefacts qui vous permettent d'utiliser les d\u00e9clarations des biblioth\u00e8ques C et Objective-C depuis le code Kotlin.) Les changements se font en coulisse, mais ce qui est visible, c'est l'augmentation des performances et la r\u00e9duction des artefacts\u00a0: les nouveaux outils produisent des biblioth\u00e8ques interop\u00e9rables jusqu'\u00e0 4 fois plus vite qu'auparavant et les artefacts font 25 \u00e0 30% de leur taille d'origine !\r\n\r\nL'utilisation de biblioth\u00e8ques interop\u00e9rables est d\u00e9sormais plus rapide car la compilation des projets Kotlin en C interop\u00e9rable prend moins de temps avec Kotlin 1.4-M2.\r\nStabilisation de la mise en cache du compilateur et de l'utilisation du d\u00e9mon Gradle\r\nDans la version 1.3.70, nous avons introduit deux nouvelles fonctionnalit\u00e9s pour am\u00e9liorer les performances de la compilation Kotlin\/Native : la mise en cache des d\u00e9pendances du projet et l'ex\u00e9cution du compilateur \u00e0 partir du d\u00e9mon Gradle. Celles-ci \u00e9tant toujours en cours de d\u00e9veloppement, certains d'entre vous ont pu rencontrer des probl\u00e8mes et un manque de stabilit\u00e9 dans certains cas.\r\n\r\nGr\u00e2ce \u00e0 vos retours, nous avons r\u00e9ussi \u00e0 corriger de nombreux probl\u00e8mes et \u00e0 am\u00e9liorer la stabilit\u00e9 globale de ces fonctionnalit\u00e9s. Donc, si vous avez eu des probl\u00e8mes avec elles, ou si vous n'avez pas eu l'occasion de tester les derni\u00e8res versions de Kotlin\/Native, c'est le moment id\u00e9al pour essayer.\r\nAm\u00e9liorations de Kotlin\/JS\r\nAvec la version 1.4-M2, la cible JavaScript de Kotlin aligne plus \u00e9troitement ses conventions de nommage Gradle avec celles des autres cibles de Kotlin. Elle permet \u00e9galement de contr\u00f4ler plus finement les param\u00e8tres du compilateur, de normaliser l'annotation @JsExport et d'activer par d\u00e9faut la prise en charge du CSS par webpack.\r\nModifications de Gradle DSL\r\nChangements de d\u00e9nomination\r\nPour nous aligner plus \u00e9troitement sur les autres cibles de Kotlin, nous avons chang\u00e9 les noms de certains \u00e9l\u00e9ments couramment utilis\u00e9s de la configuration Gradle de Kotlin\/JS. Consid\u00e9rons ce bloc de configuration par d\u00e9faut pour un projet Gradle Kotlin\/JS en 1.4-M2, qui illustre les deux changements de d\u00e9nomination que nous avons effectu\u00e9s\u00a0:\r\nkotlin {\r\n    js {\r\n        nodejs() \/\/ and\/or browser()\r\n        binaries.executable()\r\n    }\r\n}\r\n\r\n\r\n\ttarget devient js, ce qui le rend coh\u00e9rent vis-\u00e0-vis de la syntaxe utilis\u00e9e avec le plugin Kotlin multiplateforme.\r\n\tproduceExecutable(), introduit dans Kotlin 1.4-M1, devient binaries.executable(), ce qui le rend coh\u00e9rent avec la d\u00e9nomination utilis\u00e9e pour Kotlin\/Native.\r\n\r\nSi vous souhaitez en savoir plus sur ce que fait binaries.executable(), veuillez vous r\u00e9f\u00e9rer \u00e0 l'article de blog sur la version 1.4-M1, section \"Kotlin\/JS | Modifications de Gradle DSL.\r\nParam\u00e8tres de compilateur par projet\r\nAvec Kotlin 1.4-M1, nous avons notamment lanc\u00e9 le nouveau backend du compilateur IR avec un DCE optimis\u00e9, l'aper\u00e7u des d\u00e9clarations TypeScript, et un r\u00e9glage dans gradle.properties pour basculer entre les modes par d\u00e9faut, IR, et les deux modes du compilateur. La preview M2 propose un contr\u00f4le plus fin du mode de compilation utilis\u00e9 pour chaque projet, directement \u00e0 partir de la configuration de Gradle.\r\n\r\nPour passer d'un mode de compilateur \u00e0 l'autre, passez un type de compilateur \u00e0 la fonction js dans votre script de build Gradle. Par exemple\u00a0:\r\nkotlin {\r\n   js(IR) { \/\/ or: LEGACY, BOTH\r\n       \/\/ . . .\r\n   }\r\n}\r\n\r\nLe r\u00e9glage du type de compilateur pour un projet comme celui-ci remplace le r\u00e9glage par d\u00e9faut sp\u00e9cifi\u00e9 dans gradle.properties.\r\nPrise en charge du css-loader pour webpack de Gradle\r\nComme le plugin Kotlin\/JS Gradle utilise webpack par d\u00e9faut pour cr\u00e9er des artefacts pour le navigateur, il existe de nombreux param\u00e8tres qui peuvent \u00eatre personnalis\u00e9s. Bien que toutes les options puissent \u00eatre modifi\u00e9es en changeant directement les fichiers de configuration webpack qui sont utilis\u00e9s pour construire votre projet, nous voulons donner acc\u00e8s aux param\u00e8tres les plus couramment utilis\u00e9s directement via Gradle DSL.\r\n\r\nKotlin 1.4-M2 active par d\u00e9faut le css-loader de webpack pour les projets ciblant le navigateur. Cela signifie que l'ajout de CSS \u00e0 votre projet, ainsi que de d\u00e9pendances comprenant des feuilles de style, fonctionnera d\u00e9sormais sans probl\u00e8me dans la plupart des cas, sans configuration suppl\u00e9mentaire. Auparavant, vous avez pu rencontrer des erreurs telles que Module parse failed: Unexpected character '@' (14:0) dans de telles situations.\r\n\r\nSi vous souhaitez ajuster le comportement de cette int\u00e9gration CSS, vous pouvez le faire en utilisant js.browser.webpackTask.cssSettings.\r\n\r\nAvec cssSettings.enabled, vous pouvez d\u00e9terminer si votre projet doit utiliser css-loader (activ\u00e9 par d\u00e9faut).\r\n\r\nAvec cssSettings.mode, vous pouvez sp\u00e9cifier comment tout CSS rencontr\u00e9 doit \u00eatre trait\u00e9. Les valeurs suivantes sont disponibles\u00a0:\r\n\r\n\t\"inline\" (par d\u00e9faut) : les styles sont ajout\u00e9s \u00e0 la balise <style> globale.\r\n\t\"extract\"\u00a0: les styles sont extraits dans un fichier s\u00e9par\u00e9. Ils peuvent ensuite \u00eatre inclus \u00e0 partir d'une page HTML.\r\n\t\"import\"\u00a0: les styles sont trait\u00e9s comme des cha\u00eenes. Cela peut \u00eatre utile si vous avez besoin d'acc\u00e9der au CSS \u00e0 partir de votre code (par exemple val styles = require(\"main.css\")).\r\n\r\nSi vous souhaitez utiliser diff\u00e9rents modes pour le m\u00eame projet, vous pouvez utiliser cssSettings.rules. Ici, vous pouvez sp\u00e9cifier une liste de KotlinWebpackCssRules, dont chacune d\u00e9finit un mode, ainsi que des mod\u00e8les d'inclusion et d'exclusion. Pour en savoir plus sur ces mod\u00e8les, consultez la documentation webpack sur les r\u00e8gles d'inclusion et d'exclusion.\r\nNom de module personnalisable\r\nVous pouvez maintenant changer le nom du module JavaScript directement \u00e0 partir du script de build Gradle\u00a0:\r\njs {\r\n   moduleName = \"myModuleName\"\r\n}\r\n\r\nCela change le nom du module g\u00e9n\u00e9r\u00e9 dans build\/js\/packages\/myModuleName, y compris les noms de fichiers .js et .d.ts correspondants. Veuillez noter que cela n'affecte pas votre sortie webpack dans build\/distributions. Pour changer le nom du fichier webpack, vous pouvez utiliser js.browser.webpackTask.outputFileName.\r\nAnnotation @JsExport en code commun\r\nL'annotation @JsExport, que vous pouvez utiliser pour rendre une d\u00e9claration de haut niveau disponible depuis JavaScript ou TypeScript lorsque vous utilisez le backend du compilateur IR, est maintenant disponible en code commun. Ainsi, il n'est plus n\u00e9cessaire d'introduire une annotation et des typealias personnalis\u00e9s, et cela ouvre la voie pour la construction pratique de biblioth\u00e8ques JavaScript \u00e0 partir de projets Kotlin multiplateformes.\r\nAutres am\u00e9liorations et correctifs notables\r\n\r\n\tLes t\u00e2ches Gradle utilis\u00e9es pour les op\u00e9rations typiques du navigateur et des cibles nodejs sont maintenant regroup\u00e9es dans des groupes de t\u00e2ches s\u00e9par\u00e9s. Les groupes kotlin browser et kotlin node appara\u00eetront dans la fen\u00eatre d'outil Gradle dans IntelliJ IDEA ou lorsque vous listerez les t\u00e2ches via .\/gradlew tasks --all.\r\n\tLors de l'ex\u00e9cution de tests pour la cible node.js, le d\u00e9bogueur s'arr\u00eate d\u00e9sormais correctement aux points de rupture.\r\n\tPour les projets et les biblioth\u00e8ques utilisant le mode both pour la compilation, les d\u00e9pendances klib sont maintenant correctement r\u00e9solues.\r\n\r\nCompatibilit\u00e9\r\nNotez que Kotlin 1.4 n'est pas r\u00e9trocompatible avec la version 1.3 dans certains cas particuliers. Tous ces cas ont \u00e9t\u00e9 soigneusement examin\u00e9s par le comit\u00e9 du langage et seront r\u00e9pertori\u00e9s dans le \"guide de compatibilit\u00e9\" (similaire \u00e0 celui-ci). Pour le moment, vous pouvez trouver cette liste dans YouTrack.\r\nNotes de pr\u00e9-version\r\nNotez que les garanties de r\u00e9trocompatibilit\u00e9 ne concernent pas les versions pr\u00e9liminaires. Les fonctionnalit\u00e9s et l'API peuvent changer dans les versions ult\u00e9rieures. Lorsque nous atteindrons un RC final, tous les binaires produits par les versions pr\u00e9liminaires seront interdits par le compilateur et vous devrez recompiler tout ce qui a \u00e9t\u00e9 compil\u00e9 par la version 1.4 \u2011 Mx.\r\nComment essayer les derni\u00e8res fonctionnalit\u00e9s\r\nComme toujours, vous pouvez essayer Kotlin en ligne sur play.kotl.in.\r\n\r\nDans IntelliJ IDEA et Android Studio, vous pouvez mettre \u00e0 jour le plugin Kotlin vers la version 1.4-M1. Voir comment proc\u00e9der.\r\n\r\nSi vous souhaitez travailler sur des projets existants qui ont \u00e9t\u00e9 cr\u00e9\u00e9s avant d'installer la version pr\u00e9liminaire, vous devez configurer votre build pour la version Prewiew dans Gradle ou Maven.\r\n\r\nVous pouvez t\u00e9l\u00e9charger le compilateur de ligne de commande sur la page de la version sur Github.\r\n\r\nVous pouvez utiliser les versions suivantes des biblioth\u00e8ques publi\u00e9es avec cette version du langage\u00a0:\r\n\r\n\tVersion kotlinx.atomicfu\u00a0: 0.14.3-1.4-M1\r\n\tVersion kotlinx.coroutines\u00a0: 1.3.7-1.4-M1\r\n\tVersion kotlinx.serialization\u00a0: 0.20.0-1.4-M1\r\n\tVersion ktor\u00a0: 1.3.2-1.4-M2\r\n\r\nLes d\u00e9tails de la version et la liste des biblioth\u00e8ques compatibles sont \u00e9galement disponibles ici.\r\nFaites-nous part de vos commentaires\r\nNous vous serions tr\u00e8s reconnaissants de nous signaler les bugs via notre outil de suivi. Nous ferons de notre mieux pour r\u00e9soudre tous les probl\u00e8mes importants avant la version finale, afin que vous n'ayez pas \u00e0 attendre la prochaine version de Kotlin.\r\n\r\nNous vous invitons \u00e0 rejoindre le canal \\#eap sur le Slack Kotlin (demandez une invitation ici). Sur ce canal, vous pouvez poser vos questions, participer aux discussions et recevoir es notifications sur les builds des previews.\r\n\r\nFaison \u00e9voluer Kotlin ensemble !\r\nContributions externes\r\nNous remercions tous nos contributeurs externes dont les requ\u00eates pull ont \u00e9t\u00e9 incluses dans cette version\u00a0:\r\n\r\n\tToshiaki Kameyama\r\n\tVictor Turansky\r\n\tJinseong Jeon\r\n\tSteven Sch\u00e4fer\r\n\tJuan Chen\r\n\tMark Punzalan\r\n\tKristoffer Andersen\r\n\tMads Ager\r\n\tNick\r\n\tPolina Koval\r\n\tKonstantin Virolainen\r\n\tn-p-s\r\n\tJiaxiang Chen\r\n\tMatthew Gharrity\r\n\tMartynas Sateika\r\n\tNadezhda Petelimova\r\n\tPhilippe Ombredanne\r\n\tPierre-Luc Carmel Biron\r\n\tKevin Bierhoff\r\n\tScott Weber\r\n\tMiguel Serra\r\n\tIvan Gavrilovic\r\n\tIrene Dea\r\n\tHarry\r\n\tStanislav Ruban\r\n\tBrian Plummer\r\n\tAdam McNeilly\r\n\r\nAuteur de l'article original en anglais :\u00a0Ekaterina Volodko","protected":false},"excerpt":{"rendered":"Le temps passe vite et nous vous pr\u00e9sentons d\u00e9j\u00e0 en avant-premi\u00e8re plusieurs nouvelles fonctionnalit\u00e9s particuli\u00e8rement puissantes de Kotlin 1.4. D\u00e9couvrez ce que Kotlin 1.4-M2 vous r\u00e9serve, essayez-l","protected":false},"author":{"name":"Delphine Massenhove","link":"https:\/\/blog.jetbrains.com\/fr\/author\/delphine-massenhovejetbrains-com"},"featured_media":34310,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"inline_featured_image":false,"footnotes":""},"categories":[907],"tags":[600,5883],"cross-post-tag":[],"acf":[],"featured_image":"https:\/\/blog.jetbrains.com\/wp-content\/uploads\/2020\/06\/fr-kotlin-1.4-M2.png","_links":{"self":[{"href":"https:\/\/blog.jetbrains.com\/fr\/wp-json\/wp\/v2\/posts\/34309"}],"collection":[{"href":"https:\/\/blog.jetbrains.com\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.jetbrains.com\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.jetbrains.com\/fr\/wp-json\/wp\/v2\/users\/813"},{"embeddable":true,"href":"https:\/\/blog.jetbrains.com\/fr\/wp-json\/wp\/v2\/users\/813"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.jetbrains.com\/fr\/wp-json\/wp\/v2\/comments?post=34309"}],"version-history":[{"count":0,"href":"https:\/\/blog.jetbrains.com\/fr\/wp-json\/wp\/v2\/posts\/34309\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/blog.jetbrains.com\/fr\/wp-json\/wp\/v2\/media\/34310"}],"wp:attachment":[{"href":"https:\/\/blog.jetbrains.com\/fr\/wp-json\/wp\/v2\/media?parent=34309"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.jetbrains.com\/fr\/wp-json\/wp\/v2\/categories?post=34309"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.jetbrains.com\/fr\/wp-json\/wp\/v2\/tags?post=34309"},{"taxonomy":"cross-post-tag","embeddable":true,"href":"https:\/\/blog.jetbrains.com\/fr\/wp-json\/wp\/v2\/cross-post-tag?post=34309"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}