|
1 | 1 | ## 3.0.0-wip |
2 | 2 |
|
| 3 | +This is a large change. Under the hood, the formatter was almost completely |
| 4 | +rewritten, with the codebase now containing both the old and new |
| 5 | +implementations. The old formatter exists to support the older "short" style |
| 6 | +and the new code implements [the new "tall" style][tall]. |
| 7 | + |
| 8 | +[tall]: https://github.com/dart-lang/dart_style/issues/1253 |
| 9 | + |
| 10 | +The formatter uses the language version of the formatted code to determine |
| 11 | +which style you get. If the language version is 3.6 or lower, the code is |
| 12 | +formatted with the old style. If 3.7 or later, you get the new tall style. You |
| 13 | +typically control the language version by [setting a min SDK constraint in your |
| 14 | +package's pubspec][versioning]. |
| 15 | + |
| 16 | +[versioning]: https://dart.dev/guides/language/evolution |
| 17 | + |
| 18 | +In addition to the new formatting style, a number of other API and CLI changes |
| 19 | +are included, some of them breaking: |
| 20 | + |
| 21 | +* **Support project-wide page width configuration.** By long request, you can |
| 22 | + now configure your preferred formatting page width on a project-wide basis. |
| 23 | + When formatting files, the formatter will look in the file's directory and |
| 24 | + any surrounding directories for an `analysis_options.yaml` file. If it finds |
| 25 | + one, it looks for the following YAML: |
| 26 | + |
| 27 | + ```yaml |
| 28 | + formatter: |
| 29 | + page_width: 123 |
| 30 | + ``` |
| 31 | +
|
| 32 | + If it finds a `formatter` key containing a map with a `page_width` key whose |
| 33 | + value is an integer, then that is the page width that the file is formatted |
| 34 | + using. Since the formatter will walk the surrounding directories until it |
| 35 | + finds an `analysis_options.yaml` file, this can be used to globally set the |
| 36 | + page width for an entire directory, package, or even collection of packages. |
| 37 | + |
| 38 | +* **Support overriding the page width for a single file.** In code formatted |
| 39 | + using the new tall style, you can use a special marker comment to control the |
| 40 | + page width that it's formatted using: |
| 41 | + |
| 42 | + ```dart |
| 43 | + // dart format width=30 |
| 44 | + main() { |
| 45 | + someExpression + |
| 46 | + thatSplitsAt30; |
| 47 | + } |
| 48 | + ``` |
| 49 | + |
| 50 | + This comment must appear before any code in the file and must match that |
| 51 | + format exactly. The width set by the comment overrides the width set by any |
| 52 | + surrounding `analysis_options.yaml` file. |
| 53 | + |
| 54 | + This feature is mainly for code generators that generate and immediately |
| 55 | + format code but don't know about any surrounding `analysis_options.yaml` |
| 56 | + that might be configuring the page width. By inserting this comment in the |
| 57 | + generated code before formatting, it ensures that the code generator's |
| 58 | + behavior matches the behavior of `dart format`. |
| 59 | + |
| 60 | + End users should mostly use `analysis_options.yaml` for configuring their |
| 61 | + preferred page width (or do nothing and use the default page width of 80). |
| 62 | + |
| 63 | +* **Support opting out a region of code from formatting.** In code formatted |
| 64 | + using the new tall style, you can use a pair of special marker comments to |
| 65 | + opt a region of code out of automated formatting: |
| 66 | + |
| 67 | + ```dart |
| 68 | + main() { |
| 69 | + this.isFormatted(); |
| 70 | + // dart format off |
| 71 | + no + formatting |
| 72 | + + |
| 73 | + here; |
| 74 | + // dart format on |
| 75 | + formatting.isBackOnHere(); |
| 76 | + } |
| 77 | + ``` |
| 78 | + |
| 79 | + The comments must be exactly `// dart format off` and `// dart format on`. |
| 80 | + A file may have multiple regions, but they can't overlap or nest. |
| 81 | + |
| 82 | + This can be useful for highly structured data where custom layout can help |
| 83 | + a reader understand the data, like large lists of numbers. |
| 84 | + |
3 | 85 | * **Remove support for fixes and `--fix`.** The tools that come with the Dart |
4 | 86 | SDK provide two ways to apply automated changes to code: `dart format --fix` |
5 | 87 | and `dart fix`. The former is older and used to be faster. But it can only |
|
16 | 98 |
|
17 | 99 | * **Make the language version parameter to `DartFormatter()` mandatory.** This |
18 | 100 | way, the formatter always knows what language version the input is intended |
19 | | - to be treated as. Note that a `// @dart=` language version comment if present |
20 | | - overrides the specified language version. You can think of the version passed |
21 | | - to the `DartFormatter()` constructor as a "default" language version which |
22 | | - the file's contents may then override. |
| 101 | + to be treated as. Note that a `// @dart=` language version comment, if |
| 102 | + present, overrides the specified language version. You can think of the |
| 103 | + version passed to the `DartFormatter()` constructor as a "default" language |
| 104 | + version which the file's contents may then override. |
23 | 105 |
|
24 | 106 | If you don't particularly care about the version of what you're formatting, |
25 | 107 | you can pass in `DartFormatter.latestLanguageVersion` to unconditionally get |
26 | 108 | the latest language version that the formatter supports. Note that doing so |
27 | | - means you will also implicitly opt into the new tall style when that style |
28 | | - becomes available. |
| 109 | + means you will also implicitly opt into the new tall style. |
29 | 110 |
|
30 | 111 | This change only affects the library API. When using the formatter from the |
31 | 112 | command line, you can use `--language-version=` to specify a language version |
32 | 113 | or pass `--language-version=latest` to use the latest supported version. If |
33 | | - omitted, the formatter will look up the surrounding directories for a package |
| 114 | + omitted, the formatter will look in the surrounding directories for a package |
34 | 115 | config file and infer the language version for the package from that, similar |
35 | 116 | to how other Dart tools behave like `dart analyze` and `dart run`. |
36 | 117 |
|
37 | 118 | * **Remove the old formatter executables and CLI options.** Before the |
38 | 119 | `dart format` command was added to the core Dart SDK, users accessed the |
39 | 120 | formatter by running a separate `dartfmt` executable that was included with |
40 | 121 | the Dart SDK. That executable had a different CLI interface. For example, you |
41 | | - had to pass `-w` to get it to overwrite files and if you passed no arguments |
42 | | - at all, it silently sat there waiting for input on stdin. When we added |
43 | | - `dart format`, we took that opportunity to revamp the CLI options. |
| 122 | + had to pass `-w` to get it to overwrite files. When we added `dart format`, |
| 123 | + we took that opportunity to revamp the CLI options. |
44 | 124 |
|
45 | 125 | However, the dart_style package still exposed an executable with the old CLI. |
46 | 126 | If you ran `dart pub global activate dart_style`, this would give you a |
|
64 | 144 | `--language-version=`, or use `--language-version=latest` to parse the input |
65 | 145 | using the latest language version supported by the formatter. |
66 | 146 |
|
67 | | - If `--stdin-name` and `--language-version` are both omitted, then parses |
68 | | - stdin using the latest supported language version. |
69 | | - |
70 | | -* **Apply class modifiers to API classes.** The dart_style package exposes only |
71 | | - a few classes in its public API: `DartFormatter`, `SourceCode`, |
72 | | - `FormatterException`, and `UnexpectedOutputException`. None were ever |
73 | | - intended to be extended or implemented. They are now all marked `final` to |
74 | | - make that intention explicit. |
| 147 | + If `--stdin-name` and `--language-version` are both omitted, then the |
| 148 | + formatter parses stdin using the latest supported language version. |
75 | 149 |
|
76 | 150 | * **Rename the `--line-length` option to `--page-width`.** This is consistent |
77 | 151 | with the public API, internal implementation, and docs, which all use "page |
78 | 152 | width" to refer to the limit that the formatter tries to fit code into. |
79 | 153 |
|
80 | 154 | The `--line-length` name is still supported for backwards compatibility, but |
81 | 155 | may be removed at some point in the future. You're encouraged to move to |
82 | | - `--page-width`. Use of this option (however its named) is rare, and will |
| 156 | + `--page-width`. Use of this option (however it's named) is rare, and will |
83 | 157 | likely be even rarer now that project-wide configuration is supported, so |
84 | 158 | this shouldn't affect many users. |
85 | 159 |
|
| 160 | +* **Apply class modifiers to API classes.** The dart_style package exposes only |
| 161 | + a few classes in its public API: `DartFormatter`, `SourceCode`, |
| 162 | + `FormatterException`, and `UnexpectedOutputException`. None were ever |
| 163 | + intended to be extended or implemented. They are now all marked `final` to |
| 164 | + make that intention explicit. |
| 165 | + |
86 | 166 | ## 2.3.7 |
87 | 167 |
|
88 | 168 | * Allow passing a language version to `DartFomatter()`. Formatted code will be |
|
0 commit comments