Amper: una mejor experiencia de usuario en las herramientas de compilación
Una de las observaciones más frecuentes de la gente que adopta Kotlin es que la manipulación de los sistemas de compilación resulta difícil. Aunque muchos proyectos utilizan asistentes para configurar entornos de modo que estén listos para que los desarrolladores empiecen, también es necesario mantener estos asistentes. Los nuevos módulos, plataformas, dependencias y otros cambios hacen que los desarrolladores a menudo pasen más tiempo luchando contra el sistema de compilación y el IDE que centrándose en el propio trabajo. Como Kotlin se está convirtiendo en un lenguaje verdaderamente multiplataforma, este problema se acentúa aún más en las personas que entran por primera vez en el ecosistema JVM.
Desde hace algún tiempo, hemos estado trabajando en una serie de experimentos internamente en JetBrains para tratar de ver cómo podríamos mejorar esta experiencia para los desarrolladores, no solo desde la perspectiva de definir proyectos, sino también para mejorar la compatibilidad con las herramientas. Estos esfuerzos están en línea con las otras iniciativas en las que estamos trabajando para Kotlin Multiplatform.
Hoy tenemos el placer de anunciar públicamente uno de esos proyectos: Amper. Antes de continuar, sin embargo, queremos hacer una advertencia: aún es muy experimental y nuestro objetivo principal al abrirlo es validar las ideas detrás de él y recibir sus comentarios.
¿Qué es Amper?
Amper es una herramienta para la configuración de proyectos. Su objetivo es mejorar la experiencia del usuario en la configuración de proyectos y la facilidad de uso de las herramientas, es decir, la compatibilidad dentro del IDE, al tiempo que proporciona una experiencia inicial sencilla.
Actualmente, estamos evaluando varios aspectos, lo que incluye la configuración de proyectos con el propósito de compilar, empaquetar, publicar y más. No obstante, en esta etapa el principal objetivo es la configuración de proyectos con el fin de compilar.
Aunque el caso de uso actual es Kotlin y Kotlin Multiplatform, Amper también es compatible con Java y Swift (como un requisito para multiplataforma). Sin embargo, el mismo enfoque de configuración podría funcionar para otros lenguajes y pilas tecnológicas en el futuro.
Amper se implementa como un complemento de Gradle y utiliza YAML como formato de configuración de proyectos. El objetivo ahora es validar la experiencia del usuario, razón por la cual hemos optado por construir sobre una herramienta de compilación bien probada como Gradle, proporcionando una capa de configuración sobre ella.
En cuanto al uso de YAML, algunos de ustedes se preguntarán, ¿por qué no Kotlin? Aunque la decisión sobre este lenguaje de marcado no es definitiva, queremos adoptar un enfoque declarativo. Creemos que esto no solo permite una configuración más simplificada que es menos propensa a errores, sino que también nos ayuda en términos de proporcionar herramientas más efectivas. Y, de nuevo, con el objetivo de compartir este experimento con ustedes y validar las ideas detrás de él, hemos tomado el enfoque más sencillo. Todavía no se ha decidido si terminaremos con un subconjunto restrictivo de Kotlin como el lenguaje de frontend. Por ahora, nuestro enfoque es validar nuestras ideas.
¡Muéstreme el código!
Tomemos un proyecto de JVM muy básico de «Hello, World!» con la siguiente estructura de directorios en IntelliJ IDEA 2023.3:
Los archivos main.kt y MyTest.kt son simplemente archivos de Kotlin normales que no contienen nada especial. La parte interesante es module.yaml, que es el archivo de manifiesto de Amper. Para la estructura del proyecto anterior, simplemente sería:
# Produce a JVM application product: jvm/app
¡Y ya está! Las cadenas de herramientas de Kotlin y Java, el marco de trabajo de pruebas y otras funcionalidades necesarias están configuradas y disponibles directamente desde el principio. ¡Puede crear una compilación, ejecutarla, escribir y ejecutar pruebas y más! Para obtener más información detallada, eche un vistazo al ejemplo completo.
Ahora, veamos un proyecto de Compose Multiplatform con las aplicaciones de JVM para Android, iOS y escritorio, con la siguiente estructura de proyectos en Fleet:
Fíjese cómo la carpeta src/ contiene código tanto en Kotlin como en Swift. Por supuesto, también podría ser Kotlin y Java.
Otro aspecto destacable es el módulo compartido con el código común en la carpeta src y las carpetas específicas de la plataforma src@ios y src@android (obtenga más información sobre las disposiciones de proyectos).
Así es como se ve el archivo de manifiesto ios-app/module.yaml:
# Produce an iOS application product: ios/app # Depend on the shared library module: dependencies: - ../shared settings: # Enable Compose Multiplatform framework compose: enabled
Esto es bastante directo: define una aplicación de iOS con una dependencia en un módulo compartido y habilita el marco de trabajo de Compose Multiplatform. Un ejemplo más interesante sería shared/module.yaml:
# Produce a shared library for the JVM, Android, and iOS platforms:
product:
type: lib
platforms: [jvm, android, iosArm64, iosSimulatorArm64, iosX64]
# Shared Compose dependencies:
dependencies:
- org.jetbrains.compose.foundation:foundation:1.5.0-rc01: exported
- org.jetbrains.compose.material3:material3:1.5.0-rc01: exported
# Android-only dependencies
dependencies@android:
# integration compose with activities
- androidx.activity:activity-compose:1.7.2: exported
- androidx.appcompat:appcompat:1.6.1: exported
# iOS-only dependencies with a dependency on a CocoaPod
# note that CocoaPods dependencies are not yet implemented in the prototype
dependencies@ios:
- pod: 'FirebaseCore'
version: '~> 6.6'
settings:
# Enable Kotlin serialization
kotlin:
serialization: json
# Enable Compose Multiplatform framework
compose: enabled
Merece la pena mencionar un par de cosas. En primer lugar, observe las dependencias específicas de la plataforma: las secciones con el calificador @. El calificador de plataforma se puede utilizar tanto en el manifiesto como en la disposición de archivos. El calificador organiza el código, las dependencias y la configuración para una plataforma específica.
En segundo lugar, la sección dependencies: permite no solo dependencias de Kotlin y Maven, sino potencialmente también gestores de paquetes específicos de la plataforma, como CocoaPods, Swift Package Manager y otros sobre la base de los comentarios recibidos.
Naturalmente, estos ejemplos solo muestran un conjunto limitado de las funcionalidades de Amper. Eche un vistazo al proyecto en GitHub y consulte la documentación, el tutorial y los proyectos de ejemplo para obtener más información sobre el diseño y la funcionalidad de Amper.
Qué permite actualmente
Actualmente, Amper permite crear aplicaciones dirigidas a las plataformas JVM, Android, iOS, macOS y Linux. Puede crear aplicaciones basadas tanto en Kotlin (de plataforma única y multiplataforma) como en Java.
Dado que Amper utiliza Gradle como backend, la compatibilidad con tareas personalizadas, la posibilidad de publicar bibliotecas en Maven, la compatibilidad con CocoaPods y la capacidad de empaquetar aplicaciones de escritorio se proporcionan configurando directamente los archivos de compilación de Gradle.
Cómo probarlo
Hay varias maneras de probar Amper.
- En IntelliJ IDEA 2023.3, a partir de la versión 233.11799, para proyectos JVM y Android.
- En Fleet, a partir de la versión 1.26.104, para los proyectos JVM, Android y Kotlin Multiplatform.
- Utilizando Gradle para compilar proyectos de Amper desde la CLI o CI/CD.
Consulte las instrucciones de configuración.
Hemos preparado algunos ejemplos, así como un tutorial. Además, puede encontrar documentación más detallada que abarca diferentes aspectos de Amper.
Necesitamos sus comentarios
El proyecto se encuentra en una etapa en la que necesitamos desesperadamente su opinión. Nos encantaría que lo probara y nos dijera si es más sencillo para definir proyectos o qué casos de uso le gustaría que cubriera. ¡Cualquier comentario que pueda tener es bienvenido! No dude en enviar sus impresiones e ideas utilizando nuestro sistema de seguimiento de incidencias, como comentarios en esta publicación o uniéndose a nuestro canal público de Slack y publicándolos allí.
Unas últimas palabras
Hemos preparado un conjunto de preguntas frecuentes a continuación, que debería responder algunas de las preguntas que pueda tener. Sin embargo, queríamos abordar de forma explícita algunos puntos.
En primer lugar, nos comprometemos a respaldar tecnologías como Maven y Gradle en IntelliJ IDEA y Fleet. Este proyecto no cambia nuestro compromiso con estas tecnologías y continuamos trabajando muy de cerca con nuestros socios en este frente.
En segundo lugar, en esta etapa Amper no es una herramienta de compilación independiente. Aunque tenemos muchas ideas sobro cómo nos gustaría avanzar con el producto, también necesitamos validar las cosas en las que estamos trabajando antes de desarrollar Amper aún más.
Esperamos que otras preguntas le sean respondidas en las preguntas frecuentes. Si no, no dude en preguntarnos en los comentarios y le responderemos lo mejor que podamos.
Artículo original en inglés de:
Subscribe to JetBrains Blog updates
