Kotlinのビルドツールを作っている話

Kotlin Kolt

私も多分に漏れずClaude Codeを手にした人類の一人で、色々なものがサクサク作れるようになりました。
軽い気持ちでKotlinのビルドツールを作り始めたのだけど、思った以上に面白い題材で、ビルドツール設計の考え方や、実装している中で発生した課題と対処法等、ブログに残していくことにしました。

作っているもの

github.com

Koltという名前のビルドツール
Kotlinっぽくk始まりの短い名前にした。kotlin + boltの造語

  • cargoのようなtomlのマニフェストファイル
  • kotlin nativeで書かれており、実行ファイルがjvmじゃない
  • kotlinのみをターゲットにしている（jvm, nativeどちらも対応）
  • Android開発はスコープ外
  • vscodeやzed、neovim等での利用を想定

といった特徴を持つ

今の開発ステータスは、linuxX64でのみ動作して、シンプルなプロジェクトならjvm、kotlin nativeどちらも利用可能
現時点でリリースバイナリは用意できていないので、自分でビルドして使ってもらう必要がある

作ろうとしたきっかけ

まず、Kotlinってすごく良い言語だと思っていて、個人的にもっと流行ってほしい言語No1なわけです。
豊富な言語機能と表現力、nullセーフ、javaの豊富な資産を利用できる(JVMのみ) 、などなど魅力いっぱい。

ただ、Kotlinを始めてみようって人はあんまり見かけなくて、基本的にモバイルの開発者か、Java使っていた人が書き味の向上を求めて利用しているというイメージがあります。
これは、ほかの言語からやってきた人から見ると、ちょっとハードルが高く感じる要素があるからだと考えていました。

個人的に思っているのは以下のポイント

  • Gradleが複雑
  • JVMの理解が必要
  • 良くも悪くもJetBrainsと深くつながっている

このあたりを解消できるビルドツールがあると嬉しいんじゃないかなと思ってkoltを作り始めました。

どう解決をするつもりか

Tomlを使った宣言的なマニフェストファイル

Gradleは本当に何でもできる。自分が関わっているプロジェクトも、build.gradleが長い。flyway(migrationツール)の設定とかもbuild.gradleに書いてある。今まであまり疑問に思わなかったけれど、これはGradleに責務を負わせすぎだ。

kolt は cargo のように toml で宣言的に設定を行い、タスクランナーやプラグインは極力採用しない。ビルドツールはビルドに責任を負い、ほかは個別のツールでやる。そういう思想だ。

name = "my-app"
version = "0.1.0"

[kotlin]
version = "2.3.20"

[kotlin.plugins]
serialization = true

[build]
target = "jvm"
jvm_target = "17"
main = "main"
sources = ["src"]
resources = ["resources"]
test_resources = ["test-resources"]

[dependencies]
"org.jetbrains.kotlinx:kotlinx-coroutines-core" = "1.9.0"

[repositories]
central = "https://repo1.maven.org/maven2"
jitpack = "https://jitpack.io"

JVMの設定を極力やらせない

Gradle、Maven、Amper あたりは JVM 周りでハマりがちだ。JVM の言語を15年以上触ってる私ですら一発で動作しないことが多々あるんだから、最初に触る人も当然ハマる。

Kolt がこれらと根本的に違うのは、バイナリで作っているのでツール自体の動作に JVM が不要だという点だ。さらに kolt.toml で指定された Kotlin や JVM のバージョンは自動で ~/.kolt にダウンロードされる。ツールチェインを自分で管理する必要はない。ここが大きなアドバンテージだ。

VSCode、Zed、NeoVimとの統合

ここ半年くらいで Kotlin LSP が割とまともに動作するようになったという報告が相次いでいる。IDE よりも軽い環境で Kotlin を書く人が増えてきた印象だ。 Kolt はこういった環境での利用を念頭に作っている(まだ具体的な統合機能は作っていないけど)。軽い環境で Kotlin 開発を手軽にするツールとして、選択肢に入れてもらえるものを目指す。 逆に言えば、IntelliJ IDEA 等の JetBrains IDE で Gradle や Amper の体験とまともにやりあえるわけがない。ここは当然の選択だ。

とまあ、こういったコンセプトで作り始めたビルドツール。
最初は軽い気持ちで作り始めたわけなんだけど、ほどなく私はGradleの偉大さや、JVMの難しさを知ることになる。

続きはまた今度書きます。