• GitHub API を実行できるようにする
• Personal Access Token を設定したら、それが使用されるようにする
  • 使用するパッケージはよく使われているものであれば制限しない
• riverpod を導入する
• dio を導入する
• パッケージ分割はせずに、いったん apps/app の中で実装する
• 可能であれば、Interceptor で独自例外を投げるようにしたい

FYI:

• https://pub.dev/packages/flutter_native_splash

これに関する既存の Issue はありますか？

• 既存の Issue はありませんでした

動機

#62 (comment)

提案

mason.yamlの最終行に改行を追加する

• 環境によってアイコン分ける

FYI:

• https://zenn.dev/altiveinc/articles/separating-environments-in-flutter#%E3%82%A2%E3%83%97%E3%83%AAicon%E3%82%92%E7%92%B0%E5%A2%83%E5%88%A5%E3%81%AB%E5%88%86%E3%81%91%E3%82%8B%E5%A0%B4%E5%90%88%E3%81%AB%E5%BF%85%E8%A6%81%E3%81%AA%E3%81%93%E3%81%A8
• https://pub.dev/packages/flutter_launcher_icons

これに関する既存の Issue はありますか？

• 既存の Issue はありませんでした

動機

• 多言語対応をマルチパッケージ構成に対応するに取り組んだ際に、apps/app/lib/feature/setting を packages/features/settingパッケージとして切り出して、setting_page内のWidgetのAppBarに多言語対応しようと思っていました。
• しかし、apps/app/lib/feature/settingの中には、theme_mode_notifier.dartがあり、複数のパッケージから themeModeNotifierProvider が参照されてしまい、依存させたくないパッケージ同士が依存してしまう問題があると考えています。
• packages/features/setting はゆくゆくはPackages化した方が良さそうという認識があるため、themeModeNotifierProviderもパッケージの切り出しが必要だと考えています。

提案

• themeModeNotifierProviderをcores/data に切り出す。

注意点

• theme_mode_notifier.dart に記載された以下のコメント対応を行う。

/* TODO: Remove cores_data dependency from app package when this class is
     extracted into feature package
 */

• --dart-define-from-file で env ファイルに定義して環境分け
• 環境は dev, stg, prd の３つ
• README かどこかにそれぞれの環境の違いを記載

• VS Code や JetBrains IDE のアプリ起動コマンドを修正

※ アイコンや Firebase などの対応は行わない

FYI:

• https://zenn.dev/blendthink/articles/392607db0a65dd
• https://zenn.dev/altiveinc/articles/separating-environments-in-flutter

大規模プロジェクトだと、レビューレベルを設定していたほうがメリット大きそう

FYI:
https://github.com/2rabs/nito-app/blob/main/.github/PULL_REQUEST_TEMPLATE.md

アプリ全体で共通のエラーハンドリングの方法がわかっていた方が良さそう

ユーザーアクション系が欲しい
DioException のハンドリング部分

詳細な実装内容

• UI 上にサンプルボタンを設置して、ボタン押下時に何かしらの例外が発生するようにする
• 例外を受信した際に、スナックバーのようなものが常時表示されるようにする
• 外部との HTTP 通信で発生したエラー DioException を独自の例外に変換するようにする
• アプリ内で定義した独自の例外を管理する provider （以下、appExceptionProvider）を用意する
• App で appExceptionProvider を購読する処理を実装する

• melos に format コマンドを作成する
• GitHub Actions のワークフローを作成して、その中で melos format コマンドを実行して差分があればプルリクエストを作成するようにする

FYI:

• https://github.com/FlutterKaigi/2023/blob/main/.github/workflows/auto-format.yaml

• 自動生成ファイル差分チェックは git diff --name-only --exit-code を利用する

やること決まっていないため、優先度低

• yumemi_lints など
• mason でパッケージごとテンプレート化してしまってもいいかも

これに関する既存の Issue はありますか？

• 既存の Issue はありませんでした

動機

#62 (comment)

細かいですが、他の指定と同様に、影響範囲を最小限にするために現在のディレクトリからの指定をしていただければと助かります 🙏

下の mason-lock.json も同様にお願いします、、！

提案

.gitignoreを修正する

これに関する既存の Issue はありますか？

• 既存の Issue はありませんでした

動機

• #22 でデザインシステムの基本的な設定は対応する
• しかし、アプリ独自のカラーシステムが必要な場合は基本的な設定だけでは足りない

提案

• ThemeExtension を使えるように、基盤を作成しておく。
• AppColors クラスを作成して、その中に 1 つフィールドを追加する。
  • icon を用意して AppBar のアイコンのカラーに設定する。

FYI:

• https://note.com/shift_tech/n/nb4d72c1ca3ee

これに関する既存の Issue はありますか？

• 既存の Issue はありませんでした

動機

本プロジェクトのbrickは/tools/bricksにまとめられる決まりである。
そのときのmasonのコマンドはmason new <brick-name> -o /tools/bricksとなり入力が少し手間となる。
またbrickを使用できるようにするコマンドも必要で、パスを指定すると少し長い

mason add <name> --path /tools/bricks/<brick-name>

提案

brickを作成するためのbrickを作成し、brick templateを作成後、mason addコマンドも実行する

• Flutter 研修課題を参考に静的解析・テストを行う

対応しないもの

• dart run custom_lint に対応する
• キャッシュを利用する

FYI:

• https://github.com/yumemi-inc/flutter-training-template/blob/main/.github/templates/.github/workflows-templates/check-pr.yaml

これに関する既存の Issue はありますか？

• 既存の Issue はありませんでした

動機

Pull Requestで動作確認できるようになるとレビュー効率が上がる
#5 (comment)

提案

以下を参考に、アプリやwidget_bookを確認できるGitHub Actionを組む

• Flutter 導入から5年。サイバーエージェントのクロスプラットフォーム開発の現在地

これに関する既存の Issue はありますか？

• 既存の Issue はありませんでした

動機

多言語対応#3の作業時に、現状（2024/01/05）だとマルチパッケージ構成になっていないため、デザインシステムのパッケージ化#22がマージされた後に多言語対応をマルチパッケージ構成に対応する必要があるため、このIssuesを作成しました。

概要

• 多言語対応をマルチパッケージ構成に対応する

https://docs.flutter.dev/ui/accessibility-and-internationalization/internationalization
https://qiita.com/blendthink/items/ca9fddf2b977400c6259

提案

提案

概要

• fvmの導入を記載
• melosの導入を記載

これに関する既存の Issue はありますか？

• 既存の Issue はありませんでした

動機

ほぼ全ての package に必要なのに毎回設定とか面倒なのでまとめて指定できると嬉しい
#65 (comment)

提案

brickから主要パッケージを追加し、設定を簡単に生成できるようにする。

備考

build.yamlなどがすでに存在する場合、設定を追加するようなhookを作る必要がある。

対応すること

• GitHub Copilot を有効化する際の手順・注意点・参考リンクを docs/COPILOT.md に記載する
• VS Code での有効化設定を追加する

対応しないこと

• テンプレートプロジェクトとして利用したときに VS Code での有効化設定を削除する（無効にする） GitHub Actions のワークフローの作成
  • #97

• 日本語と英語を対応して、日本語をデフォルトにする

arb-dir: assets/l10n
output-dir: lib/gen/l10n
template-arb-file: app_ja.arb
output-localization-file: l10n.dart
output-class: L10n
synthetic-package: false
preferred-supported-locales:
  - ja
  - en
header: '// ignore_for_file: type=lint'
nullable-getter: false

• pubspec.yaml の generate: true の設定は削除する

FYI:

• https://docs.flutter.dev/ui/accessibility-and-internationalization/internationalization
• https://qiita.com/blendthink/items/ca9fddf2b977400c6259

このIssuesで対応しないこと

マルチパッケージ構成でも使いやすいようにする

やること決まっていないため、優先度低

• Robotパターンを導入するか検討

これに関する既存の Issue はありますか？

• 既存の Issue はありませんでした

動機

やりたいこと

こちらの PR「feat: エラーハンドリングを追加する - デバッグモードパッケージを追加する #82」で追加した debug_mode パッケージのデバッグモード画面に以下の機能を追加したい。

• メンテナンスモード有効状態時の動作確認ボタン
• 強制バージョンアップ有効状態時に動作確認ボタン

どのような問題に直面しているか？

上述した機能を debug_mode パッケージに追加する場合には、メンテナンスモードと強制バージョンアップを管理する provider を参照する必要があります。
現在この provider は app パッケージに設置されており、他のパッケージから参照するためには app パッケージに依存する必要があります。

これらの provider は app パッケージだけでなく他のパッケージから参照されて、それぞれ機能の状態の有効/無効状態を更新する必要が出てくることが考えられます。

• features/debug_mode
• features/splash（例: スプラッシュ画面で初期状態を取得する場合）

提案

以下のスクリーンショット画像の赤枠に該当するコードを core パッケージに移動する。

• Widgetbook を利用する

Navigation パッケージとして以下を導入する。

• go_router
• go_router_builder

これに関する既存の Issue はありますか？

• 既存の Issue はありませんでした

動機

#62 (comment)

提案

flutter や dart の create コマンドを実行した後に mason のコマンドを実行して必要なもののみ上書きできるようにする。

これに関する既存の Issue はありますか？

• 既存の Issue はありませんでした

動機

#64 にて対応した Pull Request でのフォーマットチェックですが、dart fix --dry-run も検証するには少し工夫が必要だったので issue を切り分けました

提案

check-format-ci.sh 内で dart fix --dry-run を実行し、修正箇所が検出されれば CI を落とすようにする

FYI: https://gist.github.com/hell0again/f5f3064ad1ea6c5c7308

• cores/designsystem に作成
• 様々な Theme の設定についてある程度網羅

FYI:

• https://docs.flutter.dev/cookbook/design/themes
• https://itome.team/blog/2019/12/flutter-advent-calendar-day12/

対応しないこと

• ダークモード設定の保存
• ThemeExtension

FYI:

• https://github.com/yumemi-inc/flutter-yumemi-lints/blob/main/.github/workflows/review-assign.yaml

• テーマ設定
  • https://pub.dev/packages/shared_preferences
• 設定画面でテーマ切り替え機能

cocoapods のバージョンを更新する

• to v1.14.3（現在の最新バージョン）
• 全体で最新のバージョンに揃えるため

これに関する既存の Issue はありますか？

• 既存の Issue はありませんでした

動機

マルチパッケージ構成におけるパッケージの分割方法やディレクトリ構造について認識合わせをするためドキュメント化する必要がある。

提案

このプロジェクトは以下のプロジェクトを参考に依存関係を構築する。
https://github.com/android/nowinandroid

cores 内のパッケージは apps 内のアプリからも features 内のパッケージからも、cores 内のパッケージからも呼び出されるものです。
features 内のパッケージは apps 内のアプリからのみ呼び出されるものです。
責務については、どう切り出すかサービスによっても変わってくるところがあるので、都度相談する

これに関する既存の Issue はありますか？

• 既存の Issue はありませんでした

動機

GitHub ワークフロー check-dff > Regenerate code ステップが失敗する

最新の main ブランチを反映していても、ワークフローが失敗することが多々ありました。

失敗したワークフローのログ: https://github.com/yumemi-inc/flutter-mobile-project-template/actions/runs/7620279114/job/20754744487

ワークフローを再試行することを複数回トライすると成功するようになることを確認しました。

失敗する原因

エラーログを見る感じでは、flutter_app パッケージの build runner が走っているときに cores_core の生成ファイルが開けないと言われていることから、app_exception_notifier_provider.g.dart ファイルがまだ生成されていない可能性があります。

[flutter_app]: PathNotFoundException: Cannot open file, path = '/home/runner/work/flutter-mobile-project-template/flutter-mobile-project-template/packages/cores/core/lib/src/exception/provider/app_exception_notifier_provider.g.dart' (OS Error: No such file or directory, errno = 2)

flutter_app パッケージは cores_core パッケージに依存しているため、cores_core パッケージの生成ファイルが完了してから、flutter_app パッケージの build_runner が走るようにしたほうがいいのではないかと思いました。

提案

パッケージ間の依存関係が影響する melos exec コマンドに以下の設定を追加します。

• concurrency: 1（default: 5）
• orderDependents: true（default: false）

concurrency

Defines the max concurrency value of how many packages will execute the command in at any one time. Defaults to 5.

参考資料: https://melos.invertase.dev/configuration/scripts#concurrency

orderDependents

Whether exec should order the execution of the script in multiple packages based on the dependency graph of the packages. The script will be executed in leaf packages first and then in packages that depend on them and so on. This is useful for example, for a script that generates code in multiple packages, which depend on each other. Defaults to false.

参考資料: https://melos.invertase.dev/configuration/scripts#orderdependents

これに関する既存の Issue はありますか？

• 既存の Issue はありませんでした

動機

masonでパッケージを追加する際、SDKバージョンはbrickテンプレートに記載されているバージョンで固定されてしまう。
プロジェクトのバージョンに合わせて自動でバージョンを設定して欲しい。

提案

brickにhooksを設定し、動的にテンプレートからコード生成を行えるようにする。

FYI:

• https://zenn.dev/razokulover/articles/d0453fd2bbeffc
• https://zenn.dev/k9i/articles/859aa1999ece9a