Publication de Kotlin 1.4-M2

Installez le plugin Kotlin 1.4 M2 incluant la prise en charge hiérarchique du projet dès maintenant !

Ajoutez l’indicateur suivant au fichier gradle.properties de votre projet :

kotlin.mpp.enableGranularSourceSetsMetadata=true

Veuillez noter que la structure hiérarchique, ainsi que tous les projets multiplateformes, nécessitent Gradle 6.0 ou une version ultérieure à compter de Kotlin 1.4-M2.

Vous pouvez créer une structure hiérarchique avec des raccourcis de cible disponibles pour des scénarios multicibles typiques ou manuellement en connectant les jeux de sources.

Par exemple, créez les deux cibles iOS et le jeu de sources partagées présenté ci-dessus avec le raccourci ios() :

kotlin { ios() // iOS device and simulator
targets; iosMain and iosTest source sets}

Pour d’autres combinaisons de cibles, créez une hiérarchie manuellement en reliant les jeux de sources à la relation dependOn.

kotlin {
 
   linuxX64()
   mingwX64()
   macosX64()
 
   sourceSets {
       ...
 
       val desktopMain by creating {
           dependsOn(commonMain)
       }
 
       val linuxX64Main by getting {
           dependsOn(desktopMain)
       }
 
       val mingwX64Main by getting {
           dependsOn(desktopMain)
       }
 
       val macosX64Main by getting {
           dependsOn(desktopMain)
       }
   }
}

Vous pouvez définir un jeu de sources partagées pour les combinaisons de cibles suivantes :

• JVM + JS + Native ;
• VM + Native ;
• JS + Native ;
• JVM + JS ;
• Natifs.

Pour l’instant, nous ne prenons pas en charge le partage d’un jeu de sources pour ces combinaisons :

• Multiples cibles JVM ;
• Cibles Android + JVM ;
• Multiples cibles JS.

N’hésitez pas à nous faire part de vos combinaisons de cibles par e-mail à l’adresse . Cela nous permettra de prioriser les combinaisons les plus courantes.

Grâce à la structure hiérarchique du projet, les bibliothèques peuvent également fournir des API communes pour un sous-ensemble de cibles.

Lorsqu’une bibliothèque est publiée, l’API de ses jeux de sources partagés est intégrée aux artefacts de la bibliothèque, avec les informations sur la structure du projet. Lorsque vous utilisez cette bibliothèque, les jeux de sources partagés de votre projet accèdent précisément aux API de la bibliothèque disponibles pour les cibles de chaque jeu de sources.

Par exemple, consultez la hiérarchie suivante des jeux de sources dans la branche native-mt du référentiel kotlinx.coroutines :

Le jeu de sources commun déclare la fonction runBlocking et est compilé pour la JVM et les cibles natives. Vous pouvez vous en servir et appeler runBlocking() à partir d’un jeu de sources partagé entre une cible JVM et des cibles natives, puisqu’il concorderait avec la « signature des cibles » du jeu de sources concurrent de la bibliothèque.

Désormais, au lieu de spécifier des dépendances sur différentes variantes de la même bibliothèque dans les jeux de sources partagés et spécifiques à la plateforme où elle est utilisée, vous ne devez spécifier une dépendance qu’une seule fois dans le jeu de sources partagées.

kotlin {
  sourceSets {
      val desktopMain by creating {
          dependencies {
               implementation("org.jetbrains.kotlinx:kotlinx-coroutines-core:1.3.7-1.4-M2")
          }
      }
  }
}

N’utilisez pas les noms d’artefacts de la bibliothèque kotlinx avec des suffixes spécifiant la plateforme, tels que -common, -native ou autre, car ils ne sont plus pris en charge. À la place, utilisez le nom de l’artefact de base de la bibliothèque, qui dans l’exemple ci-dessus est kotlinx-coroutines-core. Cependant, le changement n’affecte pas actuellement les bibliothèques stdlib et kotlin.test (stdlib-common et test-common) ; elles seront modifiées ultérieurement.

Si vous avez besoin d’une dépendance uniquement pour une plateforme spécifique, vous pouvez toujours utiliser des variantes spécifiques à la plateforme des bibliothèques standards et kotlinx avec des suffixes tels que -jvm ou -js, par exemple kotlinx-coroutines-core-jvm.

Vous pouvez utiliser des bibliothèques dépendantes de la plateforme, telles que Foundation, UIKit et posix, dans des jeux de sources partagés entre plusieurs cibles natives. Cela permet de partager davantage de code natif sans être limité par des dépendances spécifiques à la plateforme.

Aucune étape supplémentaire n’est nécessaire, tout se fait automatiquement. IntelliJ IDEA vous aidera à détecter les déclarations communes que vous pouvez utiliser dans le code partagé.

Il y a cependant certaines limites :

• cette approche ne fonctionne que pour un jeu de sources natif qui est partagé entre des jeux de sources spécifiques à la plateforme. Cela ne fonctionne pas pour les jeux de sources natifs partagés à des niveaux plus élevés de la hiérarchique du jeu de sources.
  Par exemple, si vous avez nativeDarwinMain qui est parent de watchosMain et iosMain, où iosMain a deux enfants – iosArm64Main et iosX64Main, vous pouvez utilisez des bibliothèques dépendantes de la plateforme pour iosMain seulement, mais pas pour nativeDarwinMain ;
• cette approche ne fonctionne que pour les bibliothèques interopérables fournies avec Kotlin/Native.

En savoir plus sur les détails techniques.

II-4-1. Comment l’utiliser▲

kotlin.mpp.enableGranularSourceSetsMetadata=true
kotlin.native.enableDependencyPropagation=false

II-4-2. Donner votre avis sur la structure hiérarchique▲

1. Installez le plugin Kotlin 1.4-M2.
2. Dans IntelliJ IDEA, cliquez sur File | New | Project.
3. Dans le panneau de gauche, sélectionnez Kotlin (Experimental Wizard).
4. Créez votre projet Kotlin.

Nous continuons à développer la prise en charge de l’utilisation des principales fonctionnalités de Kotlin depuis du code Swift et Objective-C. L’un des inconvénients connus des versions précédentes était leur prise en charge incomplète des coroutines Kotlin : les fonctions de suspension n’étaient pas disponibles depuis du code Swift ou Objective-C.

Dans la preview M2, nous avons le plaisir de vous présenter la prise en charge basique des fonctions de suspension dans Swift et Objective-C. Désormais, 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ête du framework généré, vous pouvez les appeler à partir de votre code Swift ou Objective-C et même les ignorer.

Par exemple, si vous écrivez cette fonction Kotlin :

suspend fun queryData(id: Int): String = ...

…alors vous pouvez l’appeler ainsi depuis Swift :

queryData(id: 17) { result, error in
   if let e = error {
       print("ERROR: \(e)")
   } else {
       print(result!)
   }
}

Veuillez noter que dans la preview M2 vous ne pouvez appeler la fonction de suspension que depuis le thread principal.

Auparavant, vous ne pouviez exécuter du code Kotlin/Native que dans le Terminal ou en exécutant une tâche Gradle dans IntelliJ IDEA. Vous pouvez maintenant l’exécuter facilement grâce à l’icône de gouttière, comme pour tout code Kotlin.

Afin d’améliorer les performances de Kotlin/Native, nous avons retravaillé la manière dont les bibliothèques C interopérables sont construites. (Ces bibliothèques sont des artefacts qui vous permettent d’utiliser les déclarations des bibliothèques 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éduction des artefacts : les nouveaux outils produisent des bibliothèques interopérables jusqu’à quatre fois plus vite qu’auparavant et les artefacts font 25 à 30 % de leur taille d’origine !

L’utilisation de bibliothèques interopérables est désormais plus rapide, car la compilation des projets Kotlin en C interopérable prend moins de temps avec Kotlin 1.4-M2.

Dans la version 1.3.70, nous avons introduit deux nouvelles fonctionnalités pour améliorer les performances de la compilation Kotlin/Native : la mise en cache des dépendances du projet et l’exécution du compilateur à partir du démon Gradle. Celles-ci étant toujours en cours de développement, certains d’entre vous ont pu rencontrer des problèmes et un manque de stabilité dans certains cas.

Grâce à vos retours, nous avons réussi à corriger de nombreux problèmes et à améliorer la stabilité globale de ces fonctionnalités. Donc, si vous avez eu des problèmes avec elles, ou si vous n’avez pas eu l’occasion de tester les dernières versions de Kotlin/Native, c’est le moment idéal pour essayer.

VII-1-1. Changements de dénomination▲

kotlin {
    js {
        nodejs() // and/or browser()
        binaries.executable()
    }
}

Avec Kotlin 1.4-M1, nous avons notamment lancé le nouveau backend du compilateur IR avec un DCE optimisé, l’aperçu des déclarations TypeScript, et un réglage dans gradle.properties pour basculer entre les modes par défaut, IR, et les deux modes du compilateur. La preview M2 propose un contrôle plus fin du mode de compilation utilisé pour chaque projet, directement à partir de la configuration de Gradle.

Pour passer d’un mode de compilateur à l’autre, passez un type de compilateur à la fonction js dans votre script de build Gradle. Par exemple :

kotlin {
   js(IR) { // or: LEGACY, BOTH
       // . . .
   }
}

Le réglage du type de compilateur pour un projet comme celui-ci remplace le réglage par défaut spécifié dans gradle.properties.

Comme le plugin Kotlin/JS Gradle utilise webpack par défaut pour créer des artefacts pour le navigateur, il existe de nombreux paramètres qui peuvent être personnalisés. Bien que toutes les options puissent être modifiées en changeant directement les fichiers de configuration webpack qui sont utilisés pour construire votre projet, nous voulons donner accès aux paramètres les plus couramment utilisés directement via Gradle DSL.

Kotlin 1.4-M2 active par défaut le css-loader de webpack pour les projets ciblant le navigateur. Cela signifie que l’ajout de CSS à votre projet, ainsi que de dépendances comprenant des feuilles de style, fonctionnera désormais sans problème dans la plupart des cas, sans configuration supplémentaire. Auparavant, vous avez pu rencontrer des erreurs telles que Module parse failed: Unexpected character '@' (14:0) dans de telles situations.

Si vous souhaitez ajuster le comportement de cette intégration CSS, vous pouvez le faire en utilisant js.browser.webpackTask.cssSettings.

Avec cssSettings.enabled, vous pouvez déterminer si votre projet doit utiliser css-loader (activé par défaut).

Avec cssSettings.mode, vous pouvez spécifier comment tout CSS rencontré doit être traité. Les valeurs suivantes sont disponibles :

• "inline" (par défaut) : les styles sont ajoutés à la balise <style> globale ;
• "extract" : les styles sont extraits dans un fichier séparé. Ils peuvent ensuite être inclus à partir d’une page HTML ;
• "import": les styles sont traités comme des chaînes. Cela peut être utile si vous avez besoin d’accéder au CSS à partir de votre code (par exemple val styles = require("main.css")).

Si vous souhaitez utiliser différents modes pour le même projet, vous pouvez utiliser cssSettings.rules. Ici, vous pouvez spécifier une liste de KotlinWebpackCssRules, dont chacune définit un mode, ainsi que des modèles d’inclusion et d’exclusion.

Pour en savoir plus sur ces modèles, consultez la documentation webpack sur les règles d’inclusion et d’exclusion.

Vous pouvez maintenant changer le nom du module JavaScript directement à partir du script de build Gradle :

js {
   moduleName = "myModuleName"
}

Cela change le nom du module généré 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.

Annotation @JsExport en code commun

L’annotation @JsExport, que vous pouvez utiliser pour rendre une déclaration 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écessaire d’introduire une annotation et des typealias personnalisés, et cela ouvre la voie pour la construction pratique de bibliothèques JavaScript à partir de projets Kotlin multiplateformes.

• Les tâches Gradle utilisées pour les opérations typiques du navigateur et des cibles nodejs sont maintenant regroupées dans des groupes de tâches séparés. Les groupes kotlin browser et kotlin node apparaîtront dans la fenêtre d’outil Gradle dans IntelliJ IDEA ou lorsque vous listerez les tâches via ./gradlew tasks --all.
• Lors de l’exécution de tests pour la cible node.js, le débogueur s’arrête désormais correctement aux points de rupture.
• Pour les projets et les bibliothèques utilisant le mode both pour la compilation, les dépendances klib sont maintenant correctement résolues.