Amper – Melhorando a experiência do usuário com ferramentas de build
As pessoas que adotam o Kotlin sempre nos dizem que acham desafiador lidar com sistemas de build. Embora muitos projetos usem assistentes para configurar ambientes para que estes estejam prontos para os desenvolvedores começarem, estes também precisam receber manutenção. Novos módulos, plataformas, dependências e outras mudanças acontecem, o que muitas vezes faz com que os desenvolvedores percam mais tempo lutando contra o sistema de build e o IDE do que realmente se concentrando no trabalho que precisam fazer. Com o Kotlin se tornando uma linguagem multiplataforma, isso é ainda mais enfatizado por pessoas que ainda são iniciantes no ecossistema JVM.
Há algum tempo, estamos trabalhando em uma série de experimentos internamente na JetBrains para descobrir como podemos melhorar essa experiência para os desenvolvedores, não apenas do ponto de vista da definição de projetos, como também fornecendo melhor suporte para ferramentas. Esses esforços estão sincronizados com outras iniciativas nas quais estamos trabalhando em relação ao Kotlin Multiplatform.
Hoje, estamos entusiasmados em compartilhar publicamente um desses projetos: o Amper. Porém, antes de prosseguirmos, gostaríamos de deixar um aviso: o projeto ainda é muito experimental, e nosso principal objetivo ao abri-lo é validar as ideias por detrás dele e receber seu feedback.
O que é o Amper?
O Amper é uma ferramenta para configuração de projetos. Seu objetivo é melhorar a experiência do usuário e o trabalho com ferramentas na configuração de projetos, ou seja, o suporte dentro do IDE, ao mesmo tempo em que proporciona uma experiência suave e pronta para uso.
Atualmente, estamos analisando vários aspectos, incluindo a configuração de projetos para fins de compilação, empacotamento, publicação e muito mais. Porém, no estágio atual, o foco está principalmente na configuração de projetos para fins de compilação.
Embora o caso de uso atual seja o Kotlin e o Kotlin Multiplatform, o Amper também oferece suporte para Java e Swift (como um requisito para multiplataforma). No entanto, a mesma abordagem de configuração poderá funcionar para outras linguagens e pilhas de tecnologia no futuro.
O Amper é implementado como um plug-in Gradle e usa YAML para o formato de configuração do projeto. O objetivo agora é validar a experiência do usuário, e é por isso que optamos por trabalhar com uma ferramenta de build bem testada como o Gradle, proporcionando uma camada de configuração além dela.
Em relação ao uso do YAML, alguns de vocês podem estar se perguntando: por que não o Kotlin? Embora a decisão sobre essa linguagem de marcação não seja definitiva, queremos adotar uma abordagem declarativa. Acreditamos que isso não só permite uma configuração mais simplificada e menos propensa a erros, como também nos ajuda a fornecer ferramentas melhores. E, novamente, para compartilhar esse experimento com você e validar as ideias por detrás dele, adotamos a abordagem mais simples. Ainda não decidimos se teremos ou não um subconjunto restritivo do Kotlin como linguagem de front-end. Por enquanto, nosso foco está na validação das nossas ideias.
Mostre-me o código!
Vamos usar um projeto JVM muito básico, “Hello, World!”, com a seguinte estrutura de diretórios no IntelliJ IDEA 2023.3:
Os arquivos main.kt e MyTest.kt são arquivos Kotlin normais, sem nada de especial. A parte interessante é module.yaml, que é o arquivo de manifesto do Amper. Para a estrutura de projeto acima, seria simplesmente:
# Produce a JVM application product: jvm/app
É isso. As toolchains Kotlin e Java, a framework de teste e outras funcionalidades necessárias são configuradas e disponibilizadas imediatamente. Você pode compilá-lo, executá-lo, escrever e executar testes e muito mais. Para informações mais detalhadas, veja o exemplo completo.
Agora, vamos dar uma olhada num projeto Compose Multiplatform com aplicativos JVM para Android, iOS e desktop, com a seguinte estrutura de projeto no Fleet:
Observe como a pasta src/ contém código Kotlin e Swift juntos. É claro que também poderia ser Kotlin e Java.
Outro aspecto a destacar é o módulo compartilhado com o código comum na pasta src e nas pastas de código específicas da plataforma src@ios e src@android (saiba mais sobre layouts de projetos).
Este é o conteúdo do arquivo de manifesto 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
Ele é bem simples: define um aplicativo iOS com dependência por um módulo compartilhado e habilita o framework Compose Multiplatform. Um exemplo mais interessante seria 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
Vale a pena mencionar algumas coisas. Primeiro, observe as seções dependencies: específicas da plataforma com o qualificador @. O qualificador de plataforma pode ser usado tanto no manifesto quanto no layout do arquivo. Ele organiza o código, as dependências e as configurações de uma determinada plataforma.
Em segundo lugar, a seção dependencies: permite não só dependências Kotlin e Maven, como potencialmente também gerenciadores de pacotes específicos de plataforma, como CocoaPods, Swift Package Manager e outros baseados no feedback que recebemos.
Naturalmente, esses exemplos mostram apenas um conjunto limitado de recursos do Amper. Confira o projeto no GitHub e veja a documentação, o tutorial e os projetos de exemplo para obter mais informações sobre o design e a funcionalidade do Amper.
O que ele suporta atualmente
Atualmente, o Amper oferece suporte à criação de aplicativos direcionados às plataformas JVM, Android, iOS, macOS e Linux. Você pode criar aplicativos baseados em Kotlin (plataforma única e multiplataforma) e Java.
Já que Amper está usando o Gradle como back-end, o suporte para tarefas personalizadas, a capacidade de publicar bibliotecas no Maven, o suporte para CocoaPods e a capacidade de empacotar aplicativos de desktop são todos fornecidos por meio da configuração direta dos arquivos de build do Gradle.
Como experimentar
Existem várias maneiras de experimentar o Amper.
- No IntelliJ IDEA 2023.3 a partir do build 233.11799, para projetos JVM e Android.
- No Fleet a partir do build 1.26.104, para projetos JVM, Android e Kotlin Multiplatform.
- Usando o Gradle para compilar projetos Amper a partir da CLI ou via CI/CD.
Confira as instruções de configuração.
Também preparamos algumas amostras, bem como um tutorial. Além disso, você poderá encontrar documentação mais detalhada que abrange diferentes aspectos do Amper.
Precisamos do seu feedback
O projeto está em um estágio em que precisamos desesperadamente do seu feedback. Adoraríamos que você o experimentasse e nos dissesse se é mais simples definir projetos ou quais casos de uso você precisa que ele possa incluir. Qualquer feedback que você possa ter será mais que bem-vindo. Sinta-se à vontade para enviar suas sugestões e ideias usando nosso rastreador de issues, como comentários nesta postagem ou participando do nosso canal público no Slack e postando comentários lá.
Algumas palavras finais
Preparamos uma lista de perguntas frequentes, que deve responder a algumas das perguntas que você possa ter. No entanto, queríamos abordar explicitamente alguns pontos.
Em primeiro lugar, estamos totalmente comprometidos em oferecer suporte a tecnologias como Maven e Gradle no IntelliJ IDEA e no Fleet. Esse projeto não altera nosso compromisso com essas tecnologias, e continuamos a trabalhar em estreita colaboração com nossos parceiros nessa frente.
Em segundo lugar, no estágio atual, o Amper não é uma ferramenta de build independente. Embora tenhamos muitas ideias sobre como gostaríamos de levar o produto adiante, também precisamos validar as coisas em que estamos trabalhando antes de continuarmos a desenvolver o Amper.
Esperamos que outras dúvidas que você possa ter sejam respondidas nas perguntas frequentes. Se não encontrar respostas, sinta-se à vontade para perguntar nos comentários e faremos o possível para respondê-los.
Artigo original em inglês por:
Subscribe to JetBrains Blog updates
