pub.devにpackageを公開してみたくて作ったけど普通に失敗して公開やめた話
Flutterエンジニアであれば、皆さん必ずお世話になってる pub.dev。
もちろん私もお世話になってますが、ふとこう思いました。
「自分でもpackage作って公開してドヤ顔したい」
そこで GW を使って実際に作ってみたけど、公開前に色々確認作業していたらどうしても譲れない部分が出てきたので、今回は公開はおろか作ったパッケージも諦めたという話です。
とはいえ、ただでは転びたくないので失敗談として Zenn で書いて、次のpackage開発のモチベにでもしようと思います。
本題
作ったpackageについて
今回作った「l10n_key_preview」というパッケージです。
これは多言語対応に関する開発支援ツールでした。
多言語対応を行うとき、コード内では Text(l10n.welcomeMessage) のように書きますが、ぱっと見このキーってなんだっけ？となることがあるかと思います。私はよくあります。
その場合、lib/l10n/app_ja.arb を見に行くわけですがそれが若干手間でした。
このパッケージは、コード内の翻訳キーの横に日本語訳をコメントとして自動的に追加することで、開発効率を向上させることを目的としていました。
例えば、
Text(l10n.welcomeMessage) // ようこそ！
このように翻訳キーの横に実際の日本語訳がコメントとして表示されるため、コードを書きながらすぐに内容を確認できます。
導入のステップとしては、
-
pubspec.yamlにパッケージを追加してpub get -
build_runnerを実行 -
ARBファイルから翻訳を読み込み、Dartファイルを解析して翻訳キーを検出し、コメントを追加する
という仕組みでした。
build_runner を実行後のファイル
何故公開をやめたのか
パッケージの開発が進み、基本機能は実装できたのですが、最終的な動作確認中に大きな問題に気づきました。
問題点：プレビュー用のファイルが新規で作成されてしまう。
当初の想定では、元のDartファイルに直接コメントを追加したかったのです。
しかしこれだと、別ファイルが出来てしまい冗長になってしまいます。
ググったりAIに聞いたりすると、build_runnerの制約として入力ファイルを直接上書きできないとのこと。へぇ〜〜〜、いつもなんとなく使っていたので知りませんでした。
しかし、これでは
- プロジェクト内のファイル数が倍増する
- エディタで実際に編集するファイルと翻訳コメントが表示されるファイルが別になる
- ビルドのたびに大量のファイルが生成される
という問題が発生し、当初想定していた「より便利になる。開発がより楽しくなる」とはかけ離れたものになってしまいました。
葛藤
一応基本機能は出来たのと、GW使って時間も使ったしなぁ、何かしら形にしたいし不出来であれどpackage公開したという実績解除はしたいなぁ。という気持ちと
現時点で自分が微妙だと思ってるものが pub.dev に公開してもゴミが増えるだけだなぁ。という気持ちで葛藤しました。
とは言え、またチャレンジ出来ること、ユーザー体験を損なう可能性があるなら諦めも肝心
という点でpackage開発は諦める事にしました。
得た事
今回のpackage開発は失敗に終わりましたが、学びもありました。
- Dartのビルドシステムへの理解：build_runnerの仕組みや制約について深く学ぶことができました
- パッケージ設計の重要性：実装前に技術的な制約をしっかり調査することの重要性を痛感しました
- pub.dev公開プロセスの理解：パッケージの公開準備を通じて、必要な要件やベストプラクティスを学びました
- （精神論）失敗を受け入れる勇気：時には「これは上手くいかない」と判断し、方向転換することも大切だと学びました
まとめ
今回は「l10n_key_preview」というパッケージの開発と公開を断念しましたが、この経験は無駄ではありませんでした。技術的な学びはもちろん、「ユーザー体験を損なうくらいなら公開しない」という判断ができたことも良かったと思います。
次回パッケージを開発するときは、今回の教訓を活かして
- 事前に技術的な制約をしっかり調査する
- ユーザー体験を最優先に考える
という点を意識していきたいと思います。
失敗は成功のもと。
次こそは「ドヤ顔」できるパッケージを公開できるよう頑張ります。
成果物
- パッケージ
- l10n_key_previewのサンプルリポジトリ
Discussion