-
Notifications
You must be signed in to change notification settings - Fork 108
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add "// dart format width=80" comment in generated code #724
Comments
cc @natebosch or @kevmoo could you take this on? |
Closes #724 The 3 places where a Dart unit can be output are as a `LibraryBuildr`, as a `PartBuilder`, or as a combined part. `SharedPartBuilder` output does not need the width comment. Add a constant for the comment and use it while writing each of the 3 types of output.
Closes #724 The 3 places where a Dart unit can be output are as a `LibraryBuildr`, as a `PartBuilder`, or as a combined part. `SharedPartBuilder` output does not need the width comment. Add a constant for the comment and use it while writing each of the 3 types of output.
It turns out we have at least 1 project which relies on being able to specify an arbitrarily large width when they format the code in order to have predictable formatting for some particular parts of the generated code where a comment is expected in a certain position I think it may be feasible to move this so that it inserts the comment during the The user visible impact is that the dart format width comment would always be the first line of the file, and it would precede any user defined headers. @kevmoo @jakemac53 - any concern about that? |
No concerns here, other than general fear about unknown unknowns |
Closes #724 A use case with a custom `formatCode` callback can reasonably use a different line width than the default, so only add the width comment when this package is responsible for performing a format. Uses with a custom header will no longer slot the width comment in following the header. Some outputs will no longer have the comment. This is not breaking since there has been no published since the comment was introduced.
Closes dart-lang/source_gen#724 The 3 places where a Dart unit can be output are as a `LibraryBuildr`, as a `PartBuilder`, or as a combined part. `SharedPartBuilder` output does not need the width comment. Add a constant for the comment and use it while writing each of the 3 types of output.
Closes dart-lang/source_gen#724 The 3 places where a Dart unit can be output are as a `LibraryBuildr`, as a `PartBuilder`, or as a combined part. `SharedPartBuilder` output does not need the width comment. Add a constant for the comment and use it while writing each of the 3 types of output.
After many years of users asking for it, we are adding support to the formatter for project-wide page width configuration using a surrounding
analysis_options.yaml
file (dart-lang/sdk#56863). However, tools like source_gen don't necessarily have access to (or want to access) IO or know where generated code will end up on disk.To avoid breaking CI by having the code get generated and formatted at one width and then get formatted to a different width when the user runs
dart format
, we also added support for putting a marker comment in a file to specify an explicit width, like:// dart format width=80
When this comment is present at the top of the file (before any code, but can be after other comments), then that comment will take precedence and the file will reliably be formatted at that width regardless of any surrounding configuration. So if code generators insert that comment at the top of the code they generate, they don't have to worry about reading the user's configuration.
This issue is requesting that source_gen be updated to add that comment to the code it generates. Since it's just a comment, it's safe to add this at any time. Let me know if you have any questions/feedback and I'll do my best.
The text was updated successfully, but these errors were encountered: