現状

Unit Test・Widget Testのセッションが存在するがGolden Testのセッションは無い。

動機

• Golden Testを入れることによりGolden TestとWidget Testでテストの役割分担ができるから。
• 実際のプロジェクトでもGolden Testは非常に役に立つから。

提案

• Widget Testセッションの次にGolden Testセッションを入れる。
• Widget TestセッションとGolden Testセッションにそれぞれの役割についてのヒントを記述する。

現状

マージ前に assign のステータスチェックが必須になっている。

動機

assign は プルリクエストが opened もしくは ready for review の際に実行される。
ブランチに対して新たな変更をプッシュしたときは実行されない。

上記の際に assign が実行されないため、ステータスチェックが通らず、マージすることができない。

提案

assign のステータスチェック必須化をなくす。

現状

具体的なことが書かれていない

動機

どのような設定をすべきか記載されていないため、混乱してしまう

提案

次の設定をするように追記する

• マージ前にプルリクエスト必須
• マージ前に１人の承認を必須
• マージ前にステータスチェック必須
• マージ前にブランチ最新化必須
• マージ前に会話の解決必須
• フォースプッシュを許可しない
• 削除を許可しない

https://docs.github.com/ja/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/about-protected-branches

現状

初期化ワークフローが二重に走ってしまう

動機

Issue が２倍作成されてしまうのを防ぎたい

提案

↓で報告されているが、テンプレートリポジトリに対してワークフローが２回実行されてしまう不具合があるらしく、この Issue 状況をウォッチしていく
actions/runner#2550

現状

yumemi という単語がパッケージ名などに含まれており、VSCode のスペルチェックに検出されている

動機

VSCode のスペルチェック対象から yumemi という単語を除外したい

提案

.vscode/settings.json にスペルチェックの除外対象として、yumemi という単語を登録する。
以下のように修正を行う想定。

{
  "dart.flutterSdkPath": ".fvm/versions/3.19.6",
  "search.exclude": {
    "**/.fvm": true
  },
  "files.watcherExclude": {
    "**/.fvm": true
  },
  "cSpell.ignoreWords": ["yumemi"] // ← この行を追加する
}

現状

何も記載されていない

動機

• GitHub Actions の権限が「Allow all actions and reusable workflows」に設定されていない場合、テンプレートプロジェクトで設定されている GitHub Actions のワークフローが実行できない
• GitHub Actions のワークフローの権限が「Read and write permissions」に設定されていない場合、テンプレートプロジェクトで設定されている GitHub Actions のワークフローが失敗してしまう

https://docs.github.com/ja/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository

提案

Session 0 に次を追記する

• GitHub Actions の権限を「Allow all actions and reusable workflows」に設定する
• GitHub Actions のワークフローの権限を「Read and write permissions」に設定する

現状

何もない

動機

Silver に関する課題がない

提案

SliverAppBar や SliverList を使用する課題を追加する

現状

template-cleanup ワークフローで実行ファイルではなく、 dart コマンド経由で実行している

動機

実行ファイルを生成してそれでプログラムを実行すれば dart への依存を無くせそう

提案

実行ファイルを生成して、リリースのアセットなどに配置しておいて、template-cleanup ワークフローではそれを利用する

現状

Session 0 で「作成した研修用のリポジトリをクローン」と記載されている

動機

ぱっと見では git clone と分かりづらい

提案

git clone と分かるように修正する

現状

yumemi_lints 2.0.0 がリリースされたら、テンプレート機能を利用して作成したプロジェクトでエラーが発生してしまう。
https://github.com/yumemi-inc/flutter-training-template/pull/62/files#r1530059665

動機

yumemi_lints 2.0.0 がもうすぐリリースされるため、対応忘れないように Issue 作成しておきたい。

提案

バージョンの記載を 3.19.3 ではなく 3.19 にする。

現状

Session 0 に Slack への通知設定などの項目がない

動機

プルリクエスト提出時にレビュアーに Slack で連絡するなどのコストがかかってしまっている

提案

Session 0 に、チャットツール（Slack など）への通知設定を行うことを追記する
https://github.com/integrations/slack

現状

何もない

動機

アニメーションに関する課題がない

提案

天気アイコンをループアニメーションさせる（size: 0.8~1.2）ような課題を追加する。

タイトル例：お天気アイコンに、ループアニメーションを適用してください

現状

tools/cleanup_template で fvm コマンドを使っている

動機

fvm コマンドを使わなくても flutter の最新の SDK を取得しさえすれば対応可能のように思ったため。

提案

fvm コマンドから Flutter SDK を取得するのではなく、

現状

Can't see API Docs on the browser.

動機

I want to see API Docs on the browser.

提案

Deploy API Docs to GitHub Pages.

現状

How do I listen to iOS lifecycle events?　

の部分のリンクが↓のようになっており、リンク切れが発生している
https://docs.flutter.dev/get-started/flutter-for/ios-devs#how-do-i-listen-to-ios-lifecycle-events

動機

以前のリンク先の内容が記載されている URL に修正する

提案

リンク先を↓に変更する
https://docs.flutter.dev/get-started/flutter-for/uikit-devs#listening-to-lifecycle-events

現状

現在は blendthink_lints と blendthink/elixir を使用している

動機

Dart や Flutter の更新に追いついていない

提案

次のものに差し替えたい

• yumemi-inc/flutter-yumemi-lints
• invertase/github-action-dart-analyzer

ついでにもろもろのアクションの更新もしたい

現状

ゆめみ社員ではなく、全く関係のない外部の人間ですが気になった箇所があったので提起です🙋‍♂️
ref: https://twitter.com/urasan_edu/status/1658702322384642048

template-cleanup.yamlファイル内で一時ディレクトリを作成しているが、ディレクトリ名を直接指定している。

動機

保守性から見てHardCodeはやめた方がいい気がします。
良いWorkFlowなので他のプロジェクトに再利用できうると思います。
そうして移行した時に移行先にtempディレクトリは割と存在しがちなので...

提案

案1

tmp_dir="$(mktemp -d)"

を使用して一時ディレクトリを作り、その後はBash内変数を使用する
(重複名を避ける意図＆改修箇所を減らす意図)

案2

GithubActionsのenvパラメータにtempを指定して、参照はtemp定数を取るようにする。
(改修箇所を減らす意図)

ゆめみさんのコーディング規約や社内ルールについて詳しくないので、とりあえず2案です。
Issue提起自体が微妙なら遠慮なくRejectしちゃってください〜。

現状

ワークフローでリポジトリ名を指定していないため、テンプレートリポジトリ機能を利用したときに Deploy api docs ワークフローが実行されてしまう。

提案

ワークフローでリポジトリ名を指定して一致しなければ実行しないようにする。

step の前に if: github.event.repository.name == 'flutter-training-template' という判定を入れると解決する見込み。

現状

何もない

動機

Key の取り扱いに関する課題がない

提案

Form を持つ設定画面を新設して、天気情報を取得する場所を入力して、呼び出し元の画面に反映するような課題を追加する

現状

現在だと Session 8 に割り当てられている https://github.com/yumemi-inc/flutter-training-template/blob/main/docs/sessions/state_management.md について。

アーキテクチャを見直し、ARCHITECTURE.md に記載する

という課題がありますが、その下の「ヒント」に riverpod_graph で生成された Provider の依存関係図が記載あり、良く考えずに見るとこのような図を作る課題に思ってしまうと感じました。

動機

同じくゆめみ社のオープンハンドブックに ARCHITECTURE.md はほとんど変更が不要な記載方法になっているか というページがあり、こちらには

• アーキテクチャの説明でなく、実装の説明になっていないか
  • 具体的なクラス名やファイル名を記載すると、リネームのたびに修正が必要になる

と記載があります。

個人的な感覚としても、アーキテクチャ図は各レイヤー同士の依存関係を俯瞰的に図示したものであり、特定のオブジェクトが出てきたり、アプリケーションに存在する全てのオブジェクトを網羅する必要は無いと感じます。

提案

本 Session の目的が私は見えていないので、具体的な方針は示せませんが、いくつか方法はあると思います。

• Provider の依存関係図も作成してもらいたい場合:
  • ARCHITECTURE.md には「アーキテクチャを概念的に図示したもの」と「Provider 同士の依存関係図」の 2 つを作成するという課題に変更 (指示を具体化) する
• Provider の依存関係図も作成しなくて良い (あくまで一例の意図だった) 場合
  • 「※ この Provider の依存関係図は riverpod_graph を利用して自動生成しました。」という文言に何かしら補足する
  • 別の図例に変更する。

現状

• 1️⃣ Session 5で使うyumemi_weatherのString fetchThrowsWeather(String area)がareaを引数に持つ
  

  flutter-training-template/packages/yumemi_weather/lib/src/yumemi_weather_base.dart

  Line 121 in 428cd36

  String fetchThrowsWeather(String area) {

• 2️⃣ 要求SDKバージョンが古い
  

  flutter-training-template/packages/yumemi_weather/pubspec.yaml

  Line 7 in 428cd36

  sdk: '>=2.18.2 <3.0.0'

動機

• 1️⃣ 研修課題を行う上でareaは必要ないと思われるが、存在しない意図を深読みして研修に集中できないかもしれないので不要なら消したい
• 2️⃣ 1️⃣のついでに更新しときたい

提案

• 1️⃣ areaを引数から消す
• 2️⃣ 公式に習ってsdk: '>=2.18.0 <4.0.0'にするのが良さそう
  firebase/flutterfire#10946

現状

.github/workflows/template-cleanup.yaml のコマンド実行で取得された最新の Flutter stable バージョンがプロジェクト内で使用される Flutter SDK バージョンという認識です。

# Install & Setup Flutter
flutterLatestVersion=$(fvm releases | grep -o -E "v?[0-9]+\.[0-9]+\.[0-9]+\s+stable" | sed -e "s/[ ]*stable//g")
fvm install "$flutterLatestVersion"
fvm use "$flutterLatestVersion" --force

https://github.com/yumemi-inc/flutter-training-template/blob/main/.github/workflows/template-cleanup.yaml#L45-L47

ここで取得した最新の Flutter stable バージョンが設定される yumemi_lints で参照するものと互換性がない場合に、Dart Analyzer が失敗します。失敗するため、yumemi_lints で用意されているバージョンにダウングレードする必要がありました。

# Override the analysis_options.yaml
cat <<EOF > analysis_options.yaml
# https://pub.dev/packages/yumemi_lints
include: package:yumemi_lints/flutter/$flutterLatestVersion/recommended.yaml
EOF

https://github.com/yumemi-inc/flutter-training-template/blob/main/.github/workflows/template-cleanup.yaml#L60-L68

動機

私がFlutter 研修課題の Session 0に対応した際に、現状で説明した状態が発生しました。

yumemi_lintsパッケージが最新の Flutter バージョンに互換性があるように対応するのは日本時間毎週金曜日となっています。

on:
  workflow_dispatch:
  schedule:
    # Schedule at 9 AM JST (0 AM UTC) every Friday
    - cron: '0 0 * * 5'

https://github.com/yumemi-inc/flutter-yumemi-lints/blob/main/.github/workflows/update-lint-rules.yaml#L3-L7

研修課題プロジェクトをスタートするタイミングによっては、私と同じように初回 Session 0 の PR 作成時に Dart Analyzer の失敗でコケてしまう人がいるように思いました。

同様のエラーが発生する人向けに何か参考資料としてエラー時の対応方法をまとめられないかと思います。

提案

• 研修課題 プロジェクトの Wiki に、今回報告するエラーの対応方法を記載したページを作成する
• 作成した Wiki を Session 0 の参考資料の項目に追加する

現状

• Mockito: https://docs.flutter.dev/cookbook/testing/unit/mocking
• Riverpod: https://docs-v2.riverpod.dev/docs/cookbooks/testing

issue 内に言及されている Mocikto のリンクは、 Flutter 公式ドキュメントであり、Mockito パッケージの公式のものではないです。
参考資料に挙げられている Riverpod のリンクは、古いガイドのものとなっています。

動機

Mockito パッケージの公式ドキュメントにはよりたくさんの情報が書いてあると同時に、モック作成時に使用する推奨アノテーションが Flutter 公式ドキュメントのものと異なります。

• Mockito 公式ドキュメント: @GenerateNiceMocks
• Flutter 公式ドキュメント: @GenerateMocks

Riverpod に関しては、最新のテストに関するドキュメントをリンクしてあげたほうが良さそうだと思いました。

提案

参考資料を以下の状態に変更する

• Testing your providers
• mockito | REAMDME