chore(deps): update dependency dart_style to ^3.1.10

[renovate]

This PR contains the following updates:

Package	Type	Update	Change
dart_style	dev_dependencies	patch	^3.1.0 → ^3.1.10

---

Warning

Some dependencies could not be looked up. Check the Dependency Dashboard for more information.

---

Release Notes

dart-lang/dart_style (dart_style)

v3.1.10

Compare Source

• Show the supported language versions in dart format --version --verbose.

Bug fixes

• Don't crash if an analysis_options.yaml file has an include that points to
  a non-existent or unreadable file (#​1840).

Style changes

The following minor style bug fixes are not language versioned and apply to all
formatted code:

• Fix a bug in eager splitting optimization that in rare cases would lead to a
  collection or argument list splitting unnecessarily (#​1809).

• Don't add a blank line before a comment at the end of a compilation unit or
  braced body (#​1644).

  If you have already formatted code using dart_style that encounters this bug,
  then reformatting it even after this fix will have no effect since the
  unneeded blank line was already added.

The following changes only apply when formatting code at language version 3.13
or higher:

• Fix a bug in an eager splitting optimization that would lead the formatter to
  prefer less desirable solutions (#​1847).

  Typically, the code affected by this bug is a call chain that contains an
  argument list with a large collection literal, as in:

  // Before:
  await MethodChannelContainer()
      .onMethodChannelInvoke("reportCrash", <String, dynamic>{
        "time": nowTime,
        "errorValue": errorName,
        "reason": reason,
        "stacktrace": stacktrace,
      });
  
  // After:
  await MethodChannelContainer().onMethodChannelInvoke(
    "reportCrash",
    <String, dynamic>{
      "time": nowTime,
      "errorValue": errorName,
      "reason": reason,
      "stacktrace": stacktrace,
    },
  );

• Prefer to split call chains for single-element targets (#​1732).

  When formatting a method call chain whose target can also split, the formatter
  must decide whether to split the target or the call chain (or both). For
  example:

  // Split target:
  function(
    argument,
  ).method().another();
  
  // Or split chain:
  function(argument)
      .method()
      .another();

  We've tried various heuristics for this over the years but most make some code
  look better while making other code look worse. This version introduces a
  relatively simple rule that seems to work well in practice: If the call chain
  target has only one element or argument, then prefer to split the call chain
  and keep the target together. So in the above example, if prefers the second
  output.

• Allow block formatting parameter lists (#​1693). The formatter supports
  "block formatting" for most bracket-delimited constructs in the language. This
  is what enables a multi-line list literal in an assignment to look like this:

  variable = [
    some,
    list,
    elements,
  ];

  Instead of:

  variable =
      [
        some,
        list,
        elements,
      ];

  This style applies to most language constructs, but function parameter lists
  were omitted. Now they are not. This rarely shows up in real code, except for
  typedefs of large function types:

  // Before:
  typedef DataViewBuilder<T> =
      Widget Function(
        BuildContext context,
        PagingState<int, T> state,
        NextPageCallback fetchNextPage,
      );
  
  // After:
  typedef DataViewBuilder<T> = Widget Function(
    BuildContext context,
    PagingState<int, T> state,
    NextPageCallback fetchNextPage,
  );

• Allow as, is, and is! expressions to be block formatted (#​1542).

  // Before:
  variable =
      function(
            argument,
            argument,
            argument,
          )
          as Type;
  
  // After:
  variable = function(
    argument,
    argument,
    argument,
  ) as Type;

• Separate imports into sections (#​1120). Following the guidelines in
  "Effective Dart", the formatter inserts a blank line between
  "dart:", "package:", and other imports:

  // Before:
  import 'dart:io';
  import 'dart:math';
  import 'package:args/args.dart';
  import 'package:test/test.dart';
  import 'my_library.dart';
  
  // After:
  import 'dart:io';
  import 'dart:math';
  
  import 'package:args/args.dart';
  import 'package:test/test.dart';
  
  import 'my_library.dart';

• In if-case statements and elements, split the guard if the pattern
  block-splits (#​1596).

  This tends to lead to code where the pattern is kept on one line and the
  guard splits:

  // Before:
  if (expression case SomeClass(
    property: var x,
  ) when guardClause(x)) {
    ...
  }
  
  // After:
  if (expression case SomeClass(property: var x)
      when guardClause(x)) {
    ...
  }

• When no solution fits the page width, prefer solutions where the overflowing
  lines have trailing string literals or comments (#​1802, #​1803, #​1837).

  Sometimes the formatter is unable to split the code in a way that fits it all
  within the page width. When this happens, the formatter prefers whatever
  solution has the fewest overflowing characters.

  In practice, overflowing solutions are usually caused by long string literals
  or comments that the user should split manually. To help the user do that, the
  formatter now treats overflowing characters caused by trailing string
  literals, comments, and a few other things that often follow a string literal
  like ,, ;, () {, or () async {, as "less bad" when comparing the
  amount of overflow between two solutions.

  The effect is that when no solution fits, the formatter tends to prefer a
  solution with hanging strings or comments, which makes it clearer to the user
  which code they need to go back and manually split.

  This change has no effect on code that does fit in the page width.

• Write a trailing comma in split extension type representation clauses when in
  a library whose language version allows it (#​1845).

  Prior to Dart 3.13, extension type representation clauses didn't allow
  trailing commas even though they syntactically appear like formal parameter
  lists. In Dart 3.13, that was fixed, so now the formatter formats them the
  same way as other parameter lists in primary constructors.

Internal changes

• Require analyzer: ^13.1.0.

v3.1.9

Compare Source

• Require analyzer: ^13.0.0.

v3.1.8

Compare Source

Style changes

• Format extension type representation clauses the same way primary constructor
  formal parameter lists are formatted. This rarely makes a difference but
  produces better formatting when the representation type is long and there are
  other clauses on the extension type, as in:

  // Before:
  extension type JSExportedDartFunction._(
    JSExportedDartFunctionRepType _jsExportedDartFunction
  )
      implements JSFunction {}
  
  // After:
  extension type JSExportedDartFunction._(
    JSExportedDartFunctionRepType _jsExportedDartFunction
  ) implements JSFunction {}

  This change is not language versioned. (The old style is always worse, and
  continuing to support it would add complexity to the formatter.)

• Force blank lines around a mixin or extension type declaration if it doesn't
  have a ; body:

  // Before:
  int above;
  extension type Inches(int x) {}
  mixin M {}
  int below;
  
  // After:
  int above;
  
  extension type Inches(int x) {}
  
  mixin M {}
  
  int below;

  The formatter already forces blank lines around class, enum, and extension
  declarations. Mixins and extension types were overlooked. This makes them
  consistent. This style change is language versioned and only affects
  libraries at 3.13 or higher.

  Note that the formatter allows classes and extension types whose body is ;
  to not have a blank line above or below them.

Internal changes

• Support upcoming Dart language version 3.13.
• Support formatting primary constructors.
• Require analyzer: '^12.0.0'.

v3.1.7

Compare Source

• Require analyzer: '>=10.0.0 <12.0.0'.

v3.1.6

Compare Source

Style changes

• When trailing commas are preserved, don't insert a newline before the ; in
  an enum with members unless there actually is a trailing comma.
  (Fix by @​Barbirosha.)

Internal changes

• Support upcoming Dart language version 3.12.
• Stop using experiment flags for features released in 3.10.
• Require sdk: ^3.10.0.

v3.1.5

Compare Source

• Support upcoming Dart language version 3.11.

v3.1.4

Compare Source

• Remove dependencies on analyzer internal implementation.
• Require analyzer: '^10.0.0'.

v3.1.3

Compare Source

• No longer format imports with configurations and a prefix in the wrong order.
  The parser used to accept this without error even though it violated the
  language spec. The parser is being fixed, so the formatter will no longer
  accept or format code like:

  import 'foo.dart' as prefix if (cond) 'bar.dart';

• Don't force a space between ? and . if a null-aware element contains a
  dot shorthand.

• Require analyzer: '>=8.2.0 <10.0.0'.

• Require args: ^2.5.0.

• Require sdk: ^3.9.0.

Bug fixes

• Respect @dart= version comments when determining which >3.7 style to apply.
  The formatter correctly used those comments to switch between the old short
  and new tall style, but ignored them for language versioned style rule changes
  after 3.7. Now the language version of the file is consistently respected for
  all style rules (#​1762).

v3.1.2

Compare Source

• Support dot shorthand syntax.
• Update to the latest package:analyzer.
• Enable language version 3.10.

Bug fixes

• Preserved trailing commas (trailing_commas: preserve) applies to record
  type annotations too (#​1721).

Style changes

This change only applies to code whose language version is 3.10 or higher:

• When trailing_commas is preserve, preserve a trailing comma after the last
  enum constant when members are present (#​1678, #​1729).

  // Before formatting:
  enum { constant, ; member() {} }
  
  // After formatting at language version 3.9 or lower:
  enum {
    constant;
  
    member() {}
  }
  
  // After formatting at language version 3.10 or higher:
  enum {
    constant,
    ;
  
    member() {}
  }

  (Thanks to jellynoone@ for this change.)

v3.1.1

Compare Source

• Show the supported language versions in dart format --version --verbose.

Bug fixes

• Don't crash if an analysis_options.yaml file has an include that points to
  a non-existent or unreadable file (#​1840).

Style changes

The following minor style bug fixes are not language versioned and apply to all
formatted code:

• Fix a bug in eager splitting optimization that in rare cases would lead to a
  collection or argument list splitting unnecessarily (#​1809).

• Don't add a blank line before a comment at the end of a compilation unit or
  braced body (#​1644).

  If you have already formatted code using dart_style that encounters this bug,
  then reformatting it even after this fix will have no effect since the
  unneeded blank line was already added.

The following changes only apply when formatting code at language version 3.13
or higher:

• Fix a bug in an eager splitting optimization that would led the formatter to
  prefer less desirable solutions (#​1847).

  Typically, the code affected by this bug is a call chain that contains an
  argument list with a large collection literal, as in:

  // Before:
  await MethodChannelContainer()
      .onMethodChannelInvoke("reportCrash", <String, dynamic>{
        "time": nowTime,
        "errorValue": errorName,
        "reason": reason,
        "stacktrace": stacktrace,
      });
  
  // After:
  await MethodChannelContainer().onMethodChannelInvoke(
    "reportCrash",
    <String, dynamic>{
      "time": nowTime,
      "errorValue": errorName,
      "reason": reason,
      "stacktrace": stacktrace,
    },
  );

• Prefer to split call chains for single-element targets (#​1732).

  When formatting a method call chain whose target can also split, the formatter
  must decide whether to split the target or the call chain (or both). For
  example:

  // Split target:
  function(
    argument,
  ).method().another();
  
  // Or split chain:
  function(argument)
      .method()
      .another();

  We've tried various heuristics for this over the years but most make some code
  look better while making other code look worse. This version introduces a
  relatively simple rule that seems to work well in practice: If the call chain
  target has only one element or argument, then prefer to split the call chain
  and keep the target together. So in the above example, if prefers the second
  output.

• Allow block formatting parameter lists (#​1693). The formatter supports
  "block formatting" for most bracket-delimited constructs in the language. This
  is what enables a multi-line list literal in an assignment to look like this:

  variable = [
    some,
    list,
    elements,
  ];

  Instead of:

  variable =
      [
        some,
        list,
        elements,
      ];

  This style applies to most language constructs, but function parameter lists
  were omitted. Now they are not. This rarely shows up in real code, except for
  typedefs of large function types:

  // Before:
  typedef DataViewBuilder<T> =
      Widget Function(
        BuildContext context,
        PagingState<int, T> state,
        NextPageCallback fetchNextPage,
      );
  
  // After:
  typedef DataViewBuilder<T> = Widget Function(
    BuildContext context,
    PagingState<int, T> state,
    NextPageCallback fetchNextPage,
  );

• Allow as, is, and is! expressions to be block formatted (#​1542).

  // Before:
  variable =
      function(
            argument,
            argument,
            argument,
          )
          as Type;
  
  // After:
  variable = function(
    argument,
    argument,
    argument,
  ) as Type;

• Separate imports into sections (#​1120). Following the guidelines in
  "Effective Dart", the formatter inserts a blank line between
  "dart:", "package:", and other imports:

  // Before:
  import 'dart:io';
  import 'dart:math';
  import 'package:args/args.dart';
  import 'package:test/test.dart';
  import 'my_library.dart';
  
  // After:
  import 'dart:io';
  import 'dart:math';
  
  import 'package:args/args.dart';
  import 'package:test/test.dart';
  
  import 'my_library.dart';

• In if-case pieces, split the guard if the pattern block-splits (#​1596).

  This tends to lead to code where the pattern is kept on one line and the
  guard splits:

  // Before:
  if (expression case SomeClass(
    property: var x,
  ) when guardClause(x)) {
    ...
  }
  
  // After:
  if (expression case SomeClass(property: var x)
      when guardClause(x)) {
    ...
  }

• When no solution fits the page width, prefer solutions where the overflowing
  lines have trailing string literals or comments (#​1802, #​1803, #​1837).

  Sometimes the formatter is unable to split the code in a way that fits it all
  within the page width. When this happens, the formatter prefers whatever
  solution has the fewest overflowing characters.

  In practice, overflowing solutions are usually caused by long string literals
  or comments that the user should split manually. To help the user do that, the
  formatter now treats overflowing characters caused by trailing string
  literals, comments, and a few other things that often follow a string literal
  like ,, ;, () {, or () async {, as "less bad" when comparing the
  amount of overflow between two solutions.

  The effect is that when no solution fits, the formatter tends to prefer a
  solution with hanging strings or comments, which makes it clearer to the user
  which code they need to go back and manually split.

  This change has no effect on code that does fit in the page width.

• Write a trailing comma in split extension type representation clauses when in
  a library whose language version allows it (#​1845).

  Prior to Dart 3.13, extension type representation clauses didn't allow
  trailing commas even though they syntactically appear like formal parameter
  lists. In Dart 3.13, that was fixed, so now the formatter formats them the
  same way as other parameter lists in primary constructors.

Internal changes

• Require analyzer: ^13.1.0.

---

Configuration

📅 Schedule: (UTC)

• Branch creation
  • At any time (no schedule defined)
• Automerge
  • At any time (no schedule defined)

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

---

• If you want to rebase/retry this PR, check this box

---

This PR was generated by Mend Renovate. View the repository job log.