analysis_options.yaml

# Enable all rules by default
include: all_lint_rules.yaml
analyzer:
  strong-mode:
    implicit-casts: false
    implicit-dynamic: false
  errors:
    dead_code: warning
    # Otherwise cause the import of all_lint_rules to warn because of some rules conflicts.
    # The conflicts are fixed in this file instead, so we can safely ignore the warning.
    included_file_warning: ignore
    missing_required_param: error
    missing_return: error
  enable-experiment:
    - non-nullable

linter:
  rules:
    # We prefer having parameters in the same order as fields https://github.com/flutter/flutter/issues/10219
    always_put_required_named_parameters_first: false

    # Depends on your needs
    always_require_non_null_named_parameters: false

    # Conflicts with `omit_local_variable_types` and other rules.
    # As per Dart guidelines, we want to avoid unnecessary types to make the code
    # more readable.
    # See https://dart.dev/guides/language/effective-dart/design#avoid-type-annotating-initialized-local-variables
    always_specify_types: false

    # conflicts with `prefer_relative_imports`
    always_use_package_imports: false

    # Conflicts with always_specify_types
    avoid_annotating_with_dynamic: false

    # There are situations where we voluntarily want to catch everything,
    # especially as a library.
    avoid_catches_without_on_clauses: false

      # Only useful when targeting JS runtime
    avoid_double_and_int_checks: false

    # Improve readbility
    avoid_function_literals_in_foreach_calls: false

    # Only useful when targeting JS runtime
    avoid_js_rounded_ints: false

    # We prefer having typedef (discussion in https://github.com/flutter/flutter/pull/16356)
    avoid_private_typedef_functions: false

    # Useful in a  lot of cases
    avoid_returning_null: false

    # Can be useful to have a more readable code
    avoid_types_on_closure_parameters: false

    # `as` is not that bad (especially with the upcoming non-nullable types).
    # Explicit exceptions is better than implicit exceptions.
    avoid_as: false

    # Can be difficult to read in some cases
    cascade_invocations: false
    
    # Not reliable enough
    close_sinks: false

    # Blocked on https://github.com/flutter/flutter/issues/20765
    comment_references: false

    # Not useful for public properties for a constructor
    diagnostic_describe_all_properties: false

    # This project doesn't use Flutter-style todos
    flutter_style_todos: false
    
    # Experimental: Too many false positives: https://github.com/dart-lang/linter/issues/811
    invariant_booleans: false

    # Can be useful to have a more readable code
    join_return_with_assignment: false

    # Not useful for comments
    lines_longer_than_80_chars: false

    # Too many false positives: https://github.com/dart-lang/sdk/issues/34181
    literal_only_boolean_expressions: false

    # Disabled for now until we have NNBD as it otherwise conflicts with `missing_return`
    no_default_cases: false

    # Can be useful to have a more readable code
    omit_local_variable_types: false
    
    # Too many false positives
    one_member_abstracts: false

    # Issue: https://github.com/flutter/flutter/issues/5792
    only_throw_errors: false

    # Issue: https://github.com/dart-lang/language/issues/32
    prefer_mixin: false

    # Intelissence do the jobs for constructors.
    prefer_asserts_with_message: false

    # More readable
    prefer_relative_imports: false

    # Conflicts with `prefer_single_quotes`
    # Single quotes are easier to type and don't compromise on readability.
    prefer_double_quotes: false

    # Conflicts with https://github.com/flutter/flutter/wiki/Style-guide-for-Flutter-repo#consider-using--for-short-functions-and-methods
    # Not quite suitable for Flutter, which may have a `build` method with a single
    # return, but that return is still complex enough that a "body" is worth it.
    prefer_expression_function_bodies: false

    # False positives
    top_level_function_literal_block: false

    # We don't want to enforce this rule now.
    sort_pub_dependencies: false

    # Too many false positives
    unawaited_futures: false

    # Has false positives: https://github.com/dart-lang/linter/issues/498
    unnecessary_lambdas: false

    # Has false positives: https://github.com/dart-lang/sdk/issues/34182
    use_string_buffers: false

    # Has false positives, so we prefer to catch this by code-review
    use_to_and_as_if_applicable: false

    # Incompatible with `prefer_final_locals`
    # Having immutable local variables makes larger functions more predictible
    # so we will use `prefer_final_locals` instead.
    unnecessary_final: false