You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
upgrade: update dependency dart_style to v3 (#615)
This PR contains the following updates:
| Package | Type | Update | Change |
|---|---|---|---|
| [dart_style](https://redirect.github.com/dart-lang/dart_style) |
dependencies | major | `^2.2.4` -> `^3.0.0` |
---
### Release Notes
<details>
<summary>dart-lang/dart_style (dart_style)</summary>
###
[`v3.0.0`](https://redirect.github.com/dart-lang/dart_style/blob/HEAD/CHANGELOG.md#300)
[Compare
Source](https://redirect.github.com/dart-lang/dart_style/compare/v2.3.7...v3.0.0)
This is a large change. Under the hood, the formatter was almost
completely
rewritten, with the codebase now containing both the old and new
implementations. The old formatter exists to support the older "short"
style
and the new code implements [the new "tall" style][tall].
[tall]: https://redirect.github.com/dart-lang/dart_style/issues/1253
The formatter uses the language version of the formatted code to
determine
which style you get. If the language version is 3.6 or lower, the code
is
formatted with the old style. If 3.7 or later, you get the new tall
style. You
typically control the language version by [setting a min SDK constraint
in your
package's pubspec][versioning].
[versioning]: https://dart.dev/guides/language/evolution
In addition to the new formatting style, a number of other API and CLI
changes
are included, some of them breaking:
- **Support project-wide page width configuration.** By long request,
you can
now configure your preferred formatting page width on a project-wide
basis.
When formatting files, the formatter will look in the file's directory
and
any surrounding directories for an `analysis_options.yaml` file. If it
finds
one, it looks for the following YAML:
```yaml
formatter:
page_width: 123
```
If it finds a `formatter` key containing a map with a `page_width` key
whose
value is an integer, then that is the page width that the file is
formatted
using. Since the formatter will walk the surrounding directories until
it
finds an `analysis_options.yaml` file, this can be used to globally set
the
page width for an entire directory, package, or even collection of
packages.
- **Support overriding the page width for a single file.** In code
formatted
using the new tall style, you can use a special marker comment to
control the
page width that it's formatted using:
```dart
// dart format width=30
main() {
someExpression +
thatSplitsAt30;
}
```
This comment must appear before any code in the file and must match that
format exactly. The width set by the comment overrides the width set by
any
surrounding `analysis_options.yaml` file.
This feature is mainly for code generators that generate and immediately
format code but don't know about any surrounding `analysis_options.yaml`
that might be configuring the page width. By inserting this comment in
the
generated code before formatting, it ensures that the code generator's
behavior matches the behavior of `dart format`.
End users should mostly use `analysis_options.yaml` for configuring
their
preferred page width (or do nothing and use the default page width of
80).
- **Support opting out a region of code from formatting.** In code
formatted
using the new tall style, you can use a pair of special marker comments
to
opt a region of code out of automated formatting:
```dart
main() {
this.isFormatted();
// dart format off
no + formatting
+
here;
// dart format on
formatting.isBackOnHere();
}
```
The comments must be exactly `// dart format off` and `// dart format
on`.
A file may have multiple regions, but they can't overlap or nest.
This can be useful for highly structured data where custom layout can
help
a reader understand the data, like large lists of numbers.
- **Remove support for fixes and `--fix`.** The tools that come with the
Dart
SDK provide two ways to apply automated changes to code: `dart format
--fix`
and `dart fix`. The former is older and used to be faster. But it can
only
apply a few fixes and hasn't been maintained in many years. The `dart
fix`
command is actively maintained, can apply all of the fixes that
`dart format --fix` could apply and many many more.
In order to avoid duplicate engineering effort, we decided to
consolidate on
`dart fix` as the one way to make automated changes that go beyond the
simple
formatting and style changes that `dart format` applies.
The ability to apply fixes is also removed from the `DartFormatter()`
library
API.
- **Make the language version parameter to `DartFormatter()`
mandatory.** This
way, the formatter always knows what language version the input is
intended
to be treated as. Note that a `// @​dart=` language version
comment, if
present, overrides the specified language version. You can think of the
version passed to the `DartFormatter()` constructor as a "default"
language
version which the file's contents may then override.
If you don't particularly care about the version of what you're
formatting,
you can pass in `DartFormatter.latestLanguageVersion` to unconditionally
get
the latest language version that the formatter supports. Note that doing
so
means you will also implicitly opt into the new tall style.
This change only affects the library API. When using the formatter from
the
command line, you can use `--language-version=` to specify a language
version
or pass `--language-version=latest` to use the latest supported version.
If
omitted, the formatter will look in the surrounding directories for a
package
config file and infer the language version for the package from that,
similar
to how other Dart tools behave like `dart analyze` and `dart run`.
- **Remove the old formatter executables and CLI options.** Before the
`dart format` command was added to the core Dart SDK, users accessed the
formatter by running a separate `dartfmt` executable that was included
with
the Dart SDK. That executable had a different CLI interface. For
example, you
had to pass `-w` to get it to overwrite files. When we added `dart
format`,
we took that opportunity to revamp the CLI options.
However, the dart_style package still exposed an executable with the old
CLI.
If you ran `dart pub global activate dart_style`, this would give you a
`dartfmt` (and `dartformat`) executable with the old CLI options. Now
that
almost everyone is using `dart format`, we have removed the old CLI and
the
old package executables.
You can still run the formatter on the CLI through the package (for
example,
if you want to use a particular version of dart_style instead of the one
bundled with your Dart SDK). But it now uses the exact same CLI options
and
arguments as the `dart format` command. You can invoke it with
`dart run dart_style:format <args...>`.
- **Treat the `--stdin-name` name as a path when inferring language
version.**
When reading input on stdin, the formatter still needs to know what
language
version to parse the code as. If the `--stdin-name` option is set, then
that
is treated as a file path and the formatter looks for a package config
surrounding that file path to infer the language version from.
If you don't want that behavior, pass in an explicit language version
using
`--language-version=`, or use `--language-version=latest` to parse the
input
using the latest language version supported by the formatter.
If `--stdin-name` and `--language-version` are both omitted, then the
formatter parses stdin using the latest supported language version.
- **Rename the `--line-length` option to `--page-width`.** This is
consistent
with the public API, internal implementation, and docs, which all use
"page
width" to refer to the limit that the formatter tries to fit code into.
The `--line-length` name is still supported for backwards compatibility,
but
may be removed at some point in the future. You're encouraged to move to
`--page-width`. Use of this option (however it's named) is rare, and
will
likely be even rarer now that project-wide configuration is supported,
so
this shouldn't affect many users.
- **Apply class modifiers to API classes.** The dart_style package
exposes only
a few classes in its public API: `DartFormatter`, `SourceCode`,
`FormatterException`, and `UnexpectedOutputException`. None were ever
intended to be extended or implemented. They are now all marked `final`
to
make that intention explicit.
- Require `package:analyzer` `>=6.5.0 <8.0.0`.
</details>
---
### Configuration
📅 **Schedule**: Branch creation - "every weekend" in timezone
Asia/Tokyo, Automerge - At any time (no schedule defined).
🚦 **Automerge**: Disabled by config. Please merge this manually once you
are satisfied.
♻ **Rebasing**: Whenever PR is behind base branch, or you tick the
rebase/retry checkbox.
🔕 **Ignore**: Close this PR and you won't be reminded about this update
again.
---
- [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check
this box
---
This PR was generated by [Mend Renovate](https://mend.io/renovate/).
View the [repository job
log](https://developer.mend.io/github/FlutterGen/flutter_gen).
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiIzOS41OC4xIiwidXBkYXRlZEluVmVyIjoiMzkuNTguMSIsInRhcmdldEJyYW5jaCI6Im1haW4iLCJsYWJlbHMiOltdfQ==-->
---------
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
Co-authored-by: Alex Li <[email protected]>
0 commit comments