Adding // ignore: prefer_initializing_formals directly above the constructor is a valid way to suppress this lint for specific cases. This is consistent with the overall approach taken in this PR to address the lint warning.

The // ignore: prefer_initializing_formals comment is correctly placed to suppress the lint for the IdeTheme constructor. This aligns with the PR's objective to resolve the lint issue.

The // ignore: prefer_initializing_formals comment is appropriately added to the _WidgetPreviewWrapperBox constructor, addressing the lint warning for this specific constructor.

Adding // ignore: prefer_initializing_formals to the WidgetPreviewScaffoldController constructor resolves the lint warning for this class, maintaining consistency with the other changes in this PR.

Disabling prefer_initializing_formals in the analysis_options.yaml file is a global change that suppresses this lint across the entire engine. While this resolves the immediate issue, it's important to ensure that this lint is not generally desired for other parts of the codebase. The comment linking to the GitHub issue provides good context for this decision.

The lint will fire on this line. If the ignore comment seems to be working where it is, then SGTM, but you may need to move it to the end of this line or one line above this one. Likewise below.

I wasn't able to reproduce the failure locally to verify. Gemini told me this is the right place for it to go. I originally had it like this:

  const IdeTheme({this.backgroundColor, this.foregroundColor, bool? isDarkMode})
    // ignore: prefer_initializing_formals
    : _isDarkMode = isDarkMode;

Having it at the beginning of the statement makes sense to me since there can be multiple instances of initializers, I'm not sure if the analyzer agrees.

I moved them, the old position didn't work as suspected. It is weird because in that one case we have 2 initializers, but only one lint failure is issued. I'm guessing one ignore is sufficient since only one failure was issued.

Style nit, but I'd put the comment outside of the parameter list so it's clearer that it applies to the initializer:

const ZoomControls({
    super.key,
    required TransformationController transformationController,
  }) : // ignore: prefer_initializing_formals
       _transformationController = transformationController;

Likewise elsewhere, but it's up to you.

Oh yea, that's nicer. I unfortunately didn't have a setup where i could reproduce the problem locally so I couldn't play around with it. I didn't know the analyzer can recognized ignores if there is non-whitespace before the comment.