Lint rules without old strong mode, but with new "stricter type checks"

[navispatial]

See also #104.

Very_good_analysis has had some changes, described below.

version 3.0.1:

analyzer:
  language:
    strict-casts: true
    strict-inference: true
    strict-raw-types: true

  errors:
    close_sinks: ignore
    missing_required_param: error
    missing_return: error

  exclude:
    - test/.test_coverage.dart
    - lib/generated_plugin_registrant.dart

version 2.4.0:

analyzer:
  strong-mode:
    implicit-casts: false
    implicit-dynamic: false

  errors:
    close_sinks: ignore
    missing_required_param: error
    missing_return: error

  exclude:
    - test/.test_coverage.dart
    - lib/generated_plugin_registrant.dart

So instead of "strong mode" settings there are now "strict mode" settings on language.

See this very_good_analysis/issues/46 that references official Dart guide Analysis options / Enabling stricter type checks.

This settings affect also as follows.

Consider an example domain model:

class Product {
  final String name;
  final double price;

  Product.fromJson(Map<String, dynamic> data)
      : name = data['name'] as String,
        price = data['price'] as double;
}

With 2.4.0 settings ("strong mode" applied), maps were required to define as:

  final product = Product.fromJson(<String, dynamic>{
    'name': 'MyBook',
    'price': 150.0,
  });

However with 3.0.1 settings ("strict mode" applied), this can be written more easily:

  final product = Product.fromJson({
    'name': 'MyBook',
    'price': 150.0,
  });

This change also has an effect on deciding #147.

[navispatial]

Also removing this from custom settings, so enforcing the rule:

    # "PREFER defining constructors instead of static methods to create
    # instances."
    # However official docs say it too, "in most cases, it makes more sense to
    # use a named constructor rather than a static method because it makes
    # instantiation clearer", but still, there are some cases where it makes
    # also sense using static method, so disable this.
    prefer_constructors_over_static_methods: false

[navispatial]

New analysis_options.yaml:

# Analysis options / lint rules (2022-08-16 / "packages edition")
#
# Documentation (official for Dart)
#     https://pub.dev/packages/lints
#     https://dart.dev/guides/language/analysis-options
#     https://dart-lang.github.io/linter/lints/
#
# Documentation (official for Flutter)
#     https://pub.dev/packages/flutter_lints
#
# Getting started (before new official Dart and Flutter lints announced!)
#     https://dash-overflow.net/articles/getting_started/
#         Some of comments originated from this blog.
#     https://rydmike.com/blog => My Flutter Linting Preferences (Jan 10, 2021)
#         Some of comments originated from this blog.
#
# Comparisons of different lints
#     https://twitter.com/RydMike/status/1426310690965532678
#         Updated lint rules comparison (Aug 14, 2021)
#         Notes about "very_good_analysis" 2.3.0+
#
# Applied package
#     https://pub.dev/packages/very_good_analysis
#     3.0.0+
#
# See also
#     https://github.com/VeryGoodOpenSource/very_good_analysis/issues/46
#     https://github.com/navibyte/geospatial/issues/148

include: package:very_good_analysis/analysis_options.yaml

analyzer:
  exclude:
    # Ignore warnings of files generated by json_serializable, built_value etc.
    - "**/*.g.dart"

    # Ignore warnings of files generated by Freezed.
    - "**/*.freezed.dart"

# Some rules that were enabled by "very_good_analysis" disabled here
linter:
  rules:
    # "DO avoid relative imports for files in lib/."
    # What's wrong with relative imports between source code inside lib.
    # So disable this rule. However "avoid_relative_lib_imports" is enabled.
    always_use_package_imports: false

    # "AVOID returning null from members whose return type is bool, double, int,
    #  or num."
    # As dart-lint is commenting, this rule has lost it's meaning after proper
    # null-safety support on Dart. And there are valid cases for returning nulls
    # even for primitive types.
    avoid_returning_null: false

    # "DO use int literals rather than the corresponding double literal."
    # It's better to use 0.0 or 342.0 for doubles than 0 and 342.
    # For example in code setting geospatial coordinates, like latitude and
    # longitude, it feels more natural using double literals always.
    prefer_int_literals: false

    # "DO sort constructor declarations before other members."
    # This rule is very opionated. Sometimes for domain data classes with lot
    # of contructors and named factories, it would be nices to put field members
    # first, then constructors. However for most of other cases the rule might
    # be good.
    # See also discussion on lint: https://github.com/passsy/dart-lint/issues/1
    sort_constructors_first: false

    # "DO sort pub dependencies in pubspec.yaml."
    # Yes do sort most of time, but sometimes better to organize logically.
    # For example first sorted list of packages from external vendors, then
    # next sorted list of custom packages.
    sort_pub_dependencies: false

[navispatial]

Implemented in release published at 2022-08-21