Ability to use short style in newer Dart versions

[Reprevise]

While there are some decent changes with the new tall style, I can't bring myself to use it at the moment due to some open issues here. That means I also can't use new Flutter/Dart releases (w/o manually formatting my changes, which I also can't be bothered to do). Is there a way that a style parameter can be passed to dart format, either tall or short? At least until support for the short style is removed (and hopefully the big outstanding issues are fixed by then).

[eernstg]

Perhaps dart format format --language-version=3.6 ... helps?

[Reprevise]

Would it throw an error if it encounters new language features like wildcard variables, etc?

[eernstg]

I think the first new language feature which is detectable by a parser (that is, the syntax didn't exist in earlier versions) is the null-aware elements of Dart 3.8 (for example, _ is not new syntax, we just stop reporting some name clashes, and a name clash is not a grammar based property). So you should be able to stay in Dart 3.6 with respect to formatting for a while.

Also, #1672 introduces the option to preserve trailing commas, and that seems to be the biggest outstanding issue at this time.

PS: @munificent would know all the details, I'm just commenting based on what I happen to know.

[munificent]

While there are some decent changes with the new tall style, I can't bring myself to use it at the moment due to some open issues here.

Which ones in particular? My hope is to get most of the pressing ones fixed soon and out in the next Dart SDK release.

Is there a way that a style parameter can be passed to dart format, either tall or short? At least until support for the short style is removed (and hopefully the big outstanding issues are fixed by then).

No, there's no support for that and no plan to support it. We don't want to have to implement formatting support for every new language feature twice, test it twice, fix bugs twice, etc.

[Reprevise]

Which ones in particular? My hope is to get most of the pressing ones fixed soon and out in the next Dart SDK release.

#1545, ternaries (#1660 (comment)), #1557 (comment).

I'm not sure if this one has an issue, but this is just unnecessary.
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,
    );

---

Lack of indenting for nested ternaries:

Before:

!hasStarted
    ? const Icon(
      Icons.hourglass_empty,
      // ...
    )
    : hasData
        ? const Icon(/* ... */)
        : const Icon(/* ... */),

!hasStarted
    ? const Icon(
      Icons.hourglass_empty,
      // ...
    )
    : hasData
    ? const Icon(/* ... */)
    : const Icon(/* ... */),

[munificent]

Which ones in particular? My hope is to get most of the pressing ones fixed soon and out in the next Dart SDK release.

#1545,

That one is tricky, but now that #1687 is in, I might be able to make some progress on it.

ternaries (#1660 (comment)),

That's #1465 and is fixed by #1687.

#1557 (comment).

Replied on that issue.

I'm not sure if this one has an issue, but this is just unnecessary. Before

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

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

Probably doable. I filed #1693 to track this.

Lack of indenting for nested ternaries:

Before:

!hasStarted
? const Icon(
Icons.hourglass_empty,
// ...
)
: hasData
? const Icon(/* ... /)
: const Icon(/ ... /),
!hasStarted
? const Icon(
Icons.hourglass_empty,
// ...
)
: hasData
? const Icon(/ ... /)
: const Icon(/ ... */),

The missing indentation in the Icons.hourglass_empty, and // ... lines is fixed by #1626. The flattened indentation is deliberate. I know there's a longer comment about it in the issue tracker somewhere, but I can't find it.

Style-wise, the idea is that it mirrors the flattened nesting of an else-if statement chain. Importantly, it also avoids a combinatorial performance problem if the conditional expressions are all formatted separately.

[munificent]

I'm going to go ahead and close this because I think the style issues are mostly tracked elsewhere. We don't intend to support the old style in later language versions. We don't want to have to implement formatting for every new language feature multiple times.

[Pingear]

Hi Benjamin @Reprevise ,

I’ve encountered similar frustrations and initially expected more flexibility from the formatter as well.

As it turns out, the Dart team has a clear position on keeping dart_style non-configurable by design. After a brief discussion (which you can read here: Request for More Open and Configurable dart_style), I came to the conclusion that the only realistic path forward is for the community to explore custom formatting solutions on top of the existing tooling.

To help lay the groundwork for that, I created a proposal focused on making it easier to create and adopt alternative formatters — without challenging the core philosophy of dart_style. You can find it here: 📌 Proposal: Official Support for Custom Formatters and Community Extensions #1695 .

There hasn't been an official response yet, but I imagine the Dart team might be waiting to see whether the community is interested before engaging further. If this aligns with your concerns, I’d really appreciate your thoughts or support.

Thanks!