page_width is another reason to disable formatting generated output

[schultek]

Not sure if this is better opened here or in the build repository. Please move where you prefer it.

I'd like to update my build_runner packages to use the new project-wide page_width setting for generated Dart code. Currently packages either generate unformatted code, or need to hardcode a page-width value or use a proprietary configuration. Using the new project wide formatter configuration would enable all build_runner packages to always generate correctly formatted code based on the users preference.

---

For example, I'm using a custom build options property 'lineLength':

var pageWidth = options.lineLength;

var formatter = DartFormatter(
  languageVersion: Version(3, 7, 0),
  pageWidth: pageWidth,
);

await buildStep.writeAsString(outputId, formatter.format(source));

What I'd like to do is this:

var pageWidth = options.lineLength;

if (pageWidth == null) {
  // This doesn't exist.
 pageWidth = DartFormatter.findPageWidthFromAnalysisOptions();
}

var formatter = DartFormatter(
  languageVersion: Version(3, 7, 0),
  pageWidth: pageWidth,
);

await buildStep.writeAsString(outputId, formatter.format(source));

However I didn't find any way to do it.

Looking through this packages source, I found the ConfigCache().findPageWidth(...) method, but this accepts a File and build strongly discourages any file based io, mainly by not giving me any file paths I could use here (it only has AssetIds).

[munificent]

I'm going to transfer this over to the build repo because I suspect that the solution here is more likely to be in the build_runner integration than in dart_style itself.

Currently packages either generate unformatted code, or need to hardcode a page-width value or use a proprietary configuration.

Yup, those are basically the options. Note that the // format width=123 syntax was added to the formatter specifically to support option 2 in generated code.

I like the idea of build_runner being able to pass in some ambient project-wide configuration, but I don't know enough about how the package works to propose a solution.

[jakemac53]

Unfortunately there can't be any perfect solution here in build_runner because the analysis_options.yaml files are not always going to be readable by the build.

However, we could support very specifically reading those files when they are at the package root. In most cases, it would likely work out.

We would have to add the analysis options file to the default publicly available sources.

[davidmorgan]

Thanks Kilian.

I'm not particularly excited about more flexible generator output: I prefer simple. Adding user preferences as a build input definitely has downsides to weigh against the benefits.

I wonder if as discussed on https://github.com/dart-lang/build/issues/3812 we should just opt generated files out of further formatting; we could do that today I think by starting the files // dart format off.

[schultek]

Thanks. I read through the linked issue and overall agree with it. It seems disabling formatting using the new formatter directives is the better approach.

So as far as I'm concerned you can close this issue then.

[davidmorgan]

Thanks! I'll keep it open as a reminder to myself, renamed the issue accordingly :)

[Reprevise]

The main issue I'm facing is the descrepency between dart format and running build_runner. The former respects the project page_width and the latter is an exclusive configuration.

[davidmorgan]

@Reprevise sorry about that--I do still plan to fix this when I address formatting generally, but it's less priority than other things because it only affects people with nonstandard config. With any luck I'll get to it this year.