New Products

Amper – ビルドツールのユーザーエクスペリエンス向上

Read this post in other languages:

Kotlin を採用したユーザーは幾度となくビルドシステムの扱いにくさを訴えてきました。 多くのプロジェクトでは開発者がすぐに作業に着手できるようにウィザードを使用して環境を構成できますが、このような環境にも保守が必要です。 新しいモジュール、プラットフォーム、依存関係などの変更があった場合、開発者が実際に取り組むべき作業に専念する時間よりもビルドシステムと IDE との格闘にかかる時間が長くなることもしばしばです。 Kotlin が真のマルチプラットフォーム言語になったことで、この傾向は JVM エコシステムを初めて使用するユーザーではさらに顕著になっています。

JetBrains 社内ではここしばらくの間、この開発者エクスペリエンスをプロジェクト定義の視点からだけでなく、より良いツール一式のサポートを提供することによってどのように改善できるかを確認するための一連の実験を行ってきました。 この取り組みは Kotlin Multiplatform に関連して取り組んでいる他のイニシアチブと連動しています。

本日、このプロジェクトの 1 つである Amper をリリースしました。 ただし、読み進める前に免責事項にご留意ください。このリリースは非常に実験的なものであり、その背後にあるアイデアを検証して皆さんからフィードバックを得ることを主な目標としています。

Amper とは?

Amper はプロジェクト構成用のツールです。 プロジェクト構成のユーザーエクスペリエンスとツールの可用性(IDE 内でのツールのサポート)を改善しながら、初期状態でスムーズなエクスペリエンスを提供することを目標としています。

現時点ではビルド、パッケージ化、公開などを目的としたプロジェクトの構成など、さまざまな場面に注目しています。 ただし、現段階では主にビルドを目的としたプロジェクトの構成に的を絞っています。

現在のユースケースは Kotlin と Kotlin Multiplatform ですが、Amper は Java と Swift も(マルチプラットフォームの要件として)サポートしています。 ただし、将来的には他の言語やテクノロジースタックにも同じ構成アプローチを使用できるようになる可能性があります。

Amper は Gradle プラグインとして実装されており、プロジェクト構成には YAML 形式を使用しています。 現時点ではユーザーエクスペリエンスを検証することを目標としているため、Gradle のような十分にテストされたビルドツールを基盤に構成レイヤーを提供して構築することにしました。

YAML の使用に関してですが、なぜ Kotlin でないのかと考える方もいらっしゃるでしょう。 このマークアップ言語での決定は最終的なものではありませんが、私たちは宣言型のアプローチを採用したいと考えています。 それによって構成がより単純化されてエラーが発生しにくくなりますし、より優れたツール一式を提供するという点でも役立つと思われるからです。 繰り返しになりますが、私たちはこのエクスペリエンスをユーザーと共有してその背後にあるアイデアを検証するため、最も単純なアプローチを取っているのです。 最終的に Kotlin の限定的なサブセットをフロントエンド言語とするかどうかはまだ決まっていません。 現時点では、このアイデアを検証することに的を絞っています。

コードを確認しましょう!

非常に基本的な JVM の「Hello, World!」プロジェクトを見てみましょう!IntelliJ IDEA 2023.3 のディレクトリ構造は以下のようになっています。

main.ktMyTest.kt ファイルは単なる通常の Kotlin ファイルであり、特別なものは含まれていません。 注目すべきなのは Amper のマニフェストファイルである module.yaml です。 上記のプロジェクト構造の場合、以下のようになります。

# Produce a JVM application 
product: jvm/app

これだけです。 Kotlin と Java のツールチェーン、テストフレームワーク、およびその他の必要な機能は初期状態で構成済みであり、そのまま使用できます。 ビルド、実行、テストの記述と実行などが可能です。 詳細については、完全な例をご覧ください。

次に、Android、iOS、デスクトップ JVM アプリを含む Compose Multiplatform プロジェクトを見てみましょう。Fleet のプロジェクト構成は以下のようになっています。

src/ フォルダーに Kotlin と Swift のコードが一緒に含まれているのが分かりますか? もちろん、Kotlin と Java である場合もあります。

もう 1 つ注目すべきなのは、共通コードを含む src フォルダーとプラットフォーム固有のコードを含む src@ios フォルダーと src@android フォルダーが shared モジュールに含まれていることです(プロジェクトレイアウトについて詳しくご覧ください)。

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

これは非常にわかりやすく書かれています。共有モジュールへの依存関係で iOS アプリケーションを定義し、Compose Multiplatform フレームワークを有効にしています。 さらに興味深い例は以下の 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

ここでは 2 つの点が重要です。 まず、@ 修飾子付きのプラットフォーム固有の dependencies: に注目してください。 プラットフォーム修飾子はマニフェストとファイルレイアウトの両方で使用できます。 この修飾子は特定プラットフォームのコード、依存関係、および設定を整理しています。
次に、dependencies: セクションでは Kotlin と Maven の依存関係だけでなく、提供されるフィードバックによっては CocoaPods や Swift Package Manager などのプラットフォーム固有のパッケージマネージャーも使用できるようになるかもしれません。

当然ながら、これらの例で示している Amper の機能はほんの一部に過ぎません。 Amper の設計と機能をさらに詳しく知るには、GitHub のプロジェクトドキュメントチュートリアルサンプルプロジェクトをご覧ください。

現在のサポート

Amper は現在、JVM、Android、iOS、macOS、Linux プラットフォームをターゲットとするアプリケーションの作成をサポートしています。 Kotlin(シングルおよびマルチプラットフォーム)と Java の両方でアプリケーションを作成できます。

Amper はバックエンドに Gradle を使用しているため、カスタムタスク、Maven にライブラリを公開する機能、CocoaPods のサポート、デスクトップアプリのパッケージ化機能はすべて、Gradle ビルドファイルを直接構成することで提供されます。

試用方法

Amper はいくつかの方法で試せます。

  • JVM と Android プロジェクトの場合は、IntelliJ IDEA 2023.3(ビルド 233.11799)を使用します。
  • JVM、Android、Kotlin Multiplatform プロジェクトの場合は、Fleet(ビルド 1.26.104)を使用します。
  • CLI または CI/CD から Amper プロジェクトをビルドするには Gradle を使用します。

セットアップ手順をご覧ください。

サンプルチュートリアルもいくつか用意しています。 さらに詳しい情報は、Amper のさまざまな要素を説明したドキュメントをご覧ください。

ご意見をお寄せください

現在、このプロジェクトは皆さんからのフィードバックを積極的に募集しています。 ぜひお試しになり、より簡単にプロジェクトを定義できるようになっているかどうかや、対応が必要なユースケースについてお聞かせください。 どのようなフィードバックでも大歓迎です。 提案やアイデアがございましたら、課題トラッカーをご利用になるか、この記事のコメント欄でお知らせください。公開 Slack チャンネルに参加し、そちらに投稿することもできます。

最後に

以下に皆さんの疑問を解消できそうな FAQ を用意しましたが、 いくつかの点については明確に説明したいと思います。

何よりもまず、私たちが Maven や Gradle などのテクノロジーを IntelliJ IDEA と Fleet でサポートすることに全力で取り組んでいることをお伝えしておきます。 このプロジェクトはこれらのテクノロジーに対する当社の取り組みを変更するものではありません。当社はこの点において引き続きパートナーと緊密に取り組んでいきます。

次に、現段階の Amper はスタンドアロン型のビルドツールではありません。 この製品をどのように進めていくかについては多くのアイデアがありますが、Amper の開発をさらに進める前に現在の取り組みを検証する必要もあります。

他の質問が FAQ で解決することを願っています。 解決しない場合は、コメント欄でご質問ください。回答するよう最善を尽くします。

オリジナル(英語)ブログ投稿記事の作者:

Ryuji Owan

Anton Makeev

image description

Discover more