chore(deps): update dependency dart_style to ^3.1.9

[renovate]

This PR contains the following updates:

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

---

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.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

• Fix bug where some collections or arguments might split unnecessarily (#​1809).

Style changes

• Support 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 for 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,
  );

  This change is language versioned and only affects code at 3.13 or higher.

• 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;

  This change is language versioned and only affects code at 3.13 or higher.

• 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)) {
  ...
}

This change is language versioned and only affects code at 3.13 or higher.

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

  In rare cases where you have a declaration with a braced body at the end of a
  block or file and there is a comment immediately after it, the formatter would
  place a blank line before the comment. It wouldn't do that if there was any
  other code after the comment.

  For example, prior to this change, if you ran the formatter on:

  main() {
    a() {
      ;
    }
    // Comment 1.
  
    b() {
      ;
    }
    // Comment 2.
  }

  It would produce:

  main() {
    a() {
      ;
    }
    // Comment 1.
  
    b() {
      ;
    }
  
    // Comment 2.
  }

  Note how a blank line was added above // Comment 2. but not // Comment 1..
  Now, it won't add a blank line before the last comment.

---

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.