【Flutter】LinterとFormatter、そしてLefthook
はじめに
インデントを揃えただけのムダなコミットが増えてきて、プルリクやコミット履歴に関係ないファイルが多くなり「これはいかん」となったので、FlutterにおけるFormatterやLinterについて調べてみました。
FormatterやLinterを調べてたら、なんとその自動化の方法やちょっとした便利なパッケージを見つけましたのでそちらもご紹介いたします。
この記事で紹介したことを導入すると、「コードの整形や解析が自動で行われ」、「正しい書き方がある程度身につき」、「import 文が見やすく」なります（最後のはおまけ）。
個人的結論
-
FormatterはDart標準搭載のもので十分 -
Linterは有名な設定を include した上でプロジェクトに沿った設定をする -
Lefthookを導入して$ git commit時に自動整形する
Linterは制約が強めなpedantic_monoを導入させていただいています。
Formatter / Linter for Flutter
コードをよしなに整形してくれるFormatter、文法やスタイルの問題をチェックするLinter（この場合に限りません）は多種多様な言語で利用されています。
Dart / Flutterにおいては、FormatterとLinterの両者ともにDartに標準搭載されています。コマンドでいうと$ dart format や$ dart analyze など。
これらはVS CodeやAndroid Studioを使う際にまず導入するであろうFlutter / Dartプラグインに含まれていますので、エディタのコマンドや問題パネルなどで知らずのうちに使っているかもしれません。
VS Code 用のプラグイン
Android Studio 用のプラグイン
FormatterはDartチームが推奨するコーディングスタイルに則っていれば問題ないと思いますが、Linterに関してはデフォルトのものよりも少し厳し目に設定しています。
コードの堅牢性やコーディングルールの統一化、パフォーマンス増強のためにも、多少指摘が煩わしくても厳しめなルールのほうがいいと考えるためです。
Formatter
コードのフォーマットは先述の通りDartに標準搭載されているもので十分です。
$ dart format [ファイル]$ dart format lib
開発中のプロジェクトで上記のコマンドを打ってみてください。コードが整形されます。
VS Codeであれば⌘+Pでコマンドパレットを開き、Format Documentからも実行できます。
こちらもVS Codeの紹介のみで恐縮ですが、設定ファイルに次のような項目を追記することでファイル保存時やペースト時に実行するよう設定できます。Android Studioでも似たような設定は可能かと思います。
"editor.formatOnSave": true,
"editor.formatOnType": true,
"editor.formatOnPaste": true,
Linter
こちらも標準搭載のものが用意されており、$ dart analyzeで『一定のルール』に基づいて解析を実行し、$ dart fix --apply libで修正可能なものについては自動修正してくれます。
こちらもプラグインを導入することで各種エディタから実行可能です。不要な import 文の削除とか、type annotationを付け足すとかです。
能動的なコードの改変が必要な修正はやってくれませんので注意しましょう。
この『一定のルール』ですが、プロジェクトのルートディレクトリにanalysis_options.yamlというファイルを追加することでカスタマイズできます。
デフォルトでルートディレクトリにanalysis_options.yamlありました。
公式のflutter/flutterプロジェクトでも例がありますね。
flutter/flutter の analysis_options.yaml
# Specify analysis options.
#
# For a list of lints, see: http://dart-lang.github.io/linter/lints/
# See the configuration guide for more
# https://github.com/dart-lang/sdk/tree/main/pkg/analyzer#configuring-the-analyzer
#
# There are other similar analysis options files in the flutter repos,
# which should be kept in sync with this file:
#
# - analysis_options.yaml (this file)
# - https://github.com/flutter/plugins/blob/master/analysis_options.yaml
# - https://github.com/flutter/engine/blob/master/analysis_options.yaml
# - https://github.com/flutter/packages/blob/master/analysis_options.yaml
#
# This file contains the analysis options used for code in the flutter/flutter
# repository.
analyzer:
language:
strict-casts: true
strict-raw-types: true
errors:
# allow self-reference to deprecated members (we do this because otherwise we have
# to annotate every member in every test, assert, etc, when we deprecate something)
deprecated_member_use_from_same_package: ignore
# Turned off until null-safe rollout is complete.
unnecessary_null_comparison: ignore
exclude:
- "bin/cache/**"
# Ignore protoc generated files
- "dev/conductor/lib/proto/*"
linter:
rules:
# This list is derived from the list of all available lints located at
# https://github.com/dart-lang/linter/blob/master/example/all.yaml
- always_declare_return_types
- always_put_control_body_on_new_line
# - always_put_required_named_parameters_first # we prefer having parameters in the same order as fields https://github.com/flutter/flutter/issues/10219
- always_require_non_null_named_parameters
- always_specify_types
# - always_use_package_imports # we do this commonly
- annotate_overrides
# - avoid_annotating_with_dynamic # conflicts with always_specify_types
- avoid_bool_literals_in_conditional_expressions
# - avoid_catches_without_on_clauses # blocked on https://github.com/dart-lang/linter/issues/3023
# - avoid_catching_errors # blocked on https://github.com/dart-lang/linter/issues/3023
- avoid_classes_with_only_static_members
- avoid_double_and_int_checks
- avoid_dynamic_calls
- avoid_empty_else
- avoid_equals_and_hash_code_on_mutable_classes
- avoid_escaping_inner_quotes
- avoid_field_initializers_in_const_classes
# - avoid_final_parameters # incompatible with prefer_final_parameters
- avoid_function_literals_in_foreach_calls
- avoid_implementing_value_types
- avoid_init_to_null
- avoid_js_rounded_ints
# - avoid_multiple_declarations_per_line # seems to be a stylistic choice we don't subscribe to
- avoid_null_checks_in_equality_operators
# - avoid_positional_boolean_parameters # would have been nice to enable this but by now there's too many places that break it
- avoid_print
# - avoid_private_typedef_functions # we prefer having typedef (discussion in https://github.com/flutter/flutter/pull/16356)
- avoid_redundant_argument_values
- avoid_relative_lib_imports
- avoid_renaming_method_parameters
- avoid_return_types_on_setters
- avoid_returning_null
- avoid_returning_null_for_future
- avoid_returning_null_for_void
# - avoid_returning_this # there are enough valid reasons to return `this` that this lint ends up with too many false positives
- avoid_setters_without_getters
- avoid_shadowing_type_parameters
- avoid_single_cascade_in_expression_statements
- avoid_slow_async_io
- avoid_type_to_string
- avoid_types_as_parameter_names
# - avoid_types_on_closure_parameters # conflicts with always_specify_types
- avoid_unnecessary_containers
- avoid_unused_constructor_parameters
- avoid_void_async
# - avoid_web_libraries_in_flutter # we use web libraries in web-specific code, and our tests prevent us from using them elsewhere
- await_only_futures
- camel_case_extensions
- camel_case_types
- cancel_subscriptions
# - cascade_invocations # doesn't match the typical style of this repo
- cast_nullable_to_non_nullable
# - close_sinks # not reliable enough
- combinators_ordering
# - comment_references # blocked on https://github.com/dart-lang/linter/issues/1142
- conditional_uri_does_not_exist
# - constant_identifier_names # needs an opt-out https://github.com/dart-lang/linter/issues/204
- control_flow_in_finally
- curly_braces_in_flow_control_structures
- depend_on_referenced_packages
- deprecated_consistency
# - diagnostic_describe_all_properties # enabled only at the framework level (packages/flutter/lib)
- directives_ordering
# - discarded_futures # not yet tested
# - do_not_use_environment # there are appropriate times to use the environment, especially in our tests and build logic
- empty_catches
- empty_constructor_bodies
- empty_statements
- eol_at_end_of_file
- exhaustive_cases
- file_names
- flutter_style_todos
- hash_and_equals
- implementation_imports
- iterable_contains_unrelated_type
# - join_return_with_assignment # not required by flutter style
- leading_newlines_in_multiline_strings
- library_names
- library_prefixes
- library_private_types_in_public_api
# - lines_longer_than_80_chars # not required by flutter style
- list_remove_unrelated_type
# - literal_only_boolean_expressions # too many false positives: https://github.com/dart-lang/linter/issues/453
- missing_whitespace_between_adjacent_strings
- no_adjacent_strings_in_list
- no_default_cases
- no_duplicate_case_values
- no_leading_underscores_for_library_prefixes
- no_leading_underscores_for_local_identifiers
- no_logic_in_create_state
# - no_runtimeType_toString # ok in tests; we enable this only in packages/
- non_constant_identifier_names
- noop_primitive_operations
- null_check_on_nullable_type_parameter
- null_closures
# - omit_local_variable_types # opposite of always_specify_types
# - one_member_abstracts # too many false positives
- only_throw_errors # this does get disabled in a few places where we have legacy code that uses strings et al
- overridden_fields
- package_api_docs
- package_names
- package_prefixed_library_names
# - parameter_assignments # we do this commonly
- prefer_adjacent_string_concatenation
- prefer_asserts_in_initializer_lists
# - prefer_asserts_with_message # not required by flutter style
- prefer_collection_literals
- prefer_conditional_assignment
- prefer_const_constructors
- prefer_const_constructors_in_immutables
- prefer_const_declarations
- prefer_const_literals_to_create_immutables
# - prefer_constructors_over_static_methods # far too many false positives
- prefer_contains
# - prefer_double_quotes # opposite of prefer_single_quotes
- prefer_equal_for_default_values
# - prefer_expression_function_bodies # conflicts with https://github.com/flutter/flutter/wiki/Style-guide-for-Flutter-repo#consider-using--for-short-functions-and-methods
- prefer_final_fields
- prefer_final_in_for_each
- prefer_final_locals
# - prefer_final_parameters # we should enable this one day when it can be auto-fixed (https://github.com/dart-lang/linter/issues/3104), see also parameter_assignments
- prefer_for_elements_to_map_fromIterable
- prefer_foreach
- prefer_function_declarations_over_variables
- prefer_generic_function_type_aliases
- prefer_if_elements_to_conditional_expressions
- prefer_if_null_operators
- prefer_initializing_formals
- prefer_inlined_adds
# - prefer_int_literals # conflicts with https://github.com/flutter/flutter/wiki/Style-guide-for-Flutter-repo#use-double-literals-for-double-constants
- prefer_interpolation_to_compose_strings
- prefer_is_empty
- prefer_is_not_empty
- prefer_is_not_operator
- prefer_iterable_whereType
# - prefer_mixin # Has false positives, see https://github.com/dart-lang/linter/issues/3018
# - prefer_null_aware_method_calls # "call()" is confusing to people new to the language since it's not documented anywhere
- prefer_null_aware_operators
- prefer_relative_imports
- prefer_single_quotes
- prefer_spread_collections
- prefer_typing_uninitialized_variables
- prefer_void_to_null
- provide_deprecation_message
# - public_member_api_docs # enabled on a case-by-case basis; see e.g. packages/analysis_options.yaml
- recursive_getters
# - require_trailing_commas # blocked on https://github.com/dart-lang/sdk/issues/47441
- secure_pubspec_urls
- sized_box_for_whitespace
# - sized_box_shrink_expand # not yet tested
- slash_for_doc_comments
- sort_child_properties_last
- sort_constructors_first
# - sort_pub_dependencies # prevents separating pinned transitive dependencies
- sort_unnamed_constructors_first
- test_types_in_equals
- throw_in_finally
- tighten_type_of_initializing_formals
# - type_annotate_public_apis # subset of always_specify_types
- type_init_formals
# - unawaited_futures # too many false positives, especially with the way AnimationController works
- unnecessary_await_in_return
- unnecessary_brace_in_string_interps
- unnecessary_const
- unnecessary_constructor_name
# - unnecessary_final # conflicts with prefer_final_locals
- unnecessary_getters_setters
# - unnecessary_lambdas # has false positives: https://github.com/dart-lang/linter/issues/498
- unnecessary_late
- unnecessary_new
- unnecessary_null_aware_assignments
- unnecessary_null_aware_operator_on_extension_on_nullable
- unnecessary_null_checks
- unnecessary_null_in_if_null_operators
- unnecessary_nullable_for_final_variable_declarations
- unnecessary_overrides
- unnecessary_parenthesis
# - unnecessary_raw_strings # what's "necessary" is a matter of opinion; consistency across strings can help readability more than this lint
- unnecessary_statements
- unnecessary_string_escapes
- unnecessary_string_interpolations
- unnecessary_this
- unnecessary_to_list_in_spreads
- unrelated_type_equality_checks
- unsafe_html
- use_build_context_synchronously
# - use_colored_box # not yet tested
# - use_decorated_box # not yet tested
# - use_enums # not yet tested
- use_full_hex_values_for_flutter_colors
- use_function_type_syntax_for_parameters
- use_if_null_to_convert_nulls_to_bools
- use_is_even_rather_than_modulo
- use_key_in_widget_constructors
- use_late_for_private_fields_and_variables
- use_named_constants
- use_raw_strings
- use_rethrow_when_possible
- use_setters_to_change_properties
# - use_string_buffers # has false positives: https://github.com/dart-lang/sdk/issues/34182
- use_super_parameters
- use_test_throws_matchers
# - use_to_and_as_if_applicable # has false positives, so we prefer to catch this by code-review
- valid_regexps
- void_checks
どういった一貫性を持てばいいのか、どういった形式に沿って書けばいいのかということに関しては以下が参考になるかもしれません。とくに、Effective DartはDartを扱う開発者にとって必読と思います。
analysis_options.yaml の書き方
DartのLinter（=静的解析）はAnalyzerとLinterから構成されます。わかりづらくてすみません。
-
Analyzer: コードに言語仕様で指定されているエラーや警告などのバグがないかを解析する。 -
Linter: コードがスタイルガイドラインに準拠しているかを解析する。
この 2 つに加えて、include: [パッケージ]と書くことでパッケージの設定項目を利用できます。
もちろん include した設定項目を上書きしたり一部を除外したりすることも可能です。
1 つ 1 つ設定するよりも、有名なパッケージを include して必要に応じて追記する方針でいいと思います。以下は選択肢になりそうなパッケージです。
Flutter チーム推奨のパッケージ（Flutter 2.5 からのデフォルト）
日本の著名な方が定めた厳しめな設定
- pedantic_mono（作者さまによる記事: Dart/Flutter の静的解析強化のススメ）
海外製の厳しめパッケージ
今の所linterのルールは追記していませんが、analyzerにFreezedなどの自動生成系のファイルを除外設定しています。これらのファイルは編集しませんし、変に改変されても嫌なので。
最近Flutter 3.3.2がリリースされたので試しに新しいカウンターアプリを作って、include ファイルをflutter_lintsから設定が厳し目なpedantic_monoにしてみました。
流石にmain.dartしかないし指摘はないだろうと思っていたのですが…
まさかのpubspec.yamlに指摘が。
pubをアルファベット順に書けとのことです。厳しい…
私のanalysis_options.yamlはこんな感じです。
...略...
include: package:pedantic_mono/analysis_options.yaml
analyzer:
exclude:
- lib/**/*.gql.dart
- lib/**/*.freezed.dart
linter:
rules:
...略...
その他の個別で設定してもいいなと思うのはこのあたりですかね。
...略...
analyzer:
exclude:
...略...
strong-mode:
# 暗黙的な型変換を禁止する
implicit-casts: false
errors:
# 何らかのルールのレベルを変更できる
# 下記は unused_import の各レベルにおける VS Code 上の挙動
unused_import: info # 画像1
unused_import: warning # 画像2
unused_import: error # 画像3
linter:
rules:
...略...
設定した重要度ごとの結果
画像 1. "info" Linter ルールはデフォルトでこちらです
画像 2. "warning"
画像 3. "error" こちらはビルドすらできなくなります
Git commit 時に実行する
ここまで色々設定しましたが、実行するのを忘れてコミットをしてしまったら意味がありません。
そこで活躍するのがLefthookです。
LefthookはGit hooksをファイルで管理するためのツールで、Go で動いているので高速です。いろいろな方法で導入できますが、macOS なら Homebrew が無難かと思います。
$ brew install lefthook
pubspec.ymlと同じディレクトリにlefthook.ymlというファイルを作成し、次のように編集します。
pre-commit:
parallel: false
commands:
linter:
run: dart fix --apply lib && git add {staged_files}
sort-imports:
glob: "*.dart"
run: flutter pub run import_sorter:main {staged_files} && git add {staged_files}
formatter:
glob: "*.dart"
run: dart format {staged_files} && git add {staged_files}
こちらがLefthookの設定ファイルになります。
pre-commit
commit の直前という意味になります。
$ git commitと打った瞬間に実行され、処理が終了されるとファイルがコミットされます。
pre-push とすることで$ git pushの直前に実行できます。
parallel
並列処理をするかどうか選択します。
今回は確実にformatterが最後に動いてほしかったので false としていますが、速度を求めるなら true のほうがいいと思います。
command
実行してほしい処理を記述します。
-
run: 実行するコマンド -
glob: ファイルのフィルタリング
他にもいろんなオプションがありますので気になる方はこちらのGitHubをご覧ください。
またLefthookには便利な変数のようなものが用意されています。
-
{staged_files}: ステージング環境にあるファイル -
{all_files}: git によって追跡されているすべてのファイル
import_sorter
こちらはおまけですが、Flutterの長ったらしいインポート文をいい感じに整形してくれるライブラリです。
pubspec.yamlのdev_dependenciesに追記しましょう。
dev_dependencies:
...略...
import_sorter: ^4.6.0
...略...
$ flutter pub get
いいタイミングで見つけたのでLefthookにも記述してみました。
ここまで設定できたらGit hooksに反映させるため、$ lefthook installとコマンドを打ちます。
これにて$ git commit時に設定ファイルの内容が実行されます。
画像の例では、left_hook_test.dartに不要なimport 'dart:async';という行が残ったままになっています。
ステージング環境にファイルが追加されていることを確認して、$ git commitします。
最後のSUMMARYですべてのコマンドが成功したことがわかります。
$ dart fixが結構時間かかるので、コミット完了まで 40 秒くらい掛かりました。
そしてファイルを確認すると、ちゃんと整形されたあとにコミットされていました。
import_sorterによって import 文もいい感じに並べ替えてくれてますね。
Lefthook、今回はFlutterの記述しかしていませんがテストとかビルド関係の設定とかを書いてもよさそうですね。
またチームで設定を共有することで余計な差分が消え、コードのスタイルの統一化を強制できるので是非導入したいですね。
以上になります。
Discussion