At a high level, having a single method that calls other methods based on a list of enums set in the object's constructor is confusing. Some of the checks aren't really checks either, like clear temp dir.

I would start by making each of these tasks performed by a public method, which documents what it is doing and named appropriately whether it is performing some cleanup or verification. I would also leave out this enum setup, at least for now, and we can discuss that more when you're further along the integration side of things.

(That would also remove a lot of the confusion about arguments that are only required conditionally)

In general RegExps should be hoisted into statics and extensively documented as to what they are intended to match.

Do you need a specific diff format here, or is there a way to do this in Dart? In general, we need to be really careful about introducing new runtime dependencies.

I prefer unidiff so that I can recommend a patch command to quickly apply all diffs, but if that is not possible the diff can still be displayed in other formats for developer reference. Overall, this step is not necessary for the function of this feature, but it provides helpful quality of life improvements.

I am not aware of any fully-dart ways to do this. The diff commands are more complex than it seems. For unix, diff should always be available. On windows however, fc is less powerful and doesn't generate the diffs I want. I am exploring using git diff instead. Since flutter requires git, git diff seems to be a relatively safe dependency.

In the worst case, if the commands for some reason cannot be run successfully, the diff step can be skipped without any material impact on the results of this validation.

I'm actually going to remove the diff task from this PR. I'll land a more fully developed version of it in the future. Meanwhile I'd like to get the rest of the PR moving along.

This would need to be done before this feature is landed

Prefer to inject globals into the constructor

If you use printError that will end up with error/red text. I would not spend too much time specifically formatting the errors

This is a dangerous pattern because forgetting to clear might lead to future tests passing inadvertently

I'll use the setup method to avoid this.

out of date comment.

Can you link to an example/docs on what structure this is looking for in settings.gradle?

Isn't this a user-owned file? How can we be sure that it can be safely deleted, and that the parsing will work correctly on valid but differently formatted files?

ahh, misread settingsGradle and settingsGradleOutput

prefer to write the file all at once, since it is not particularly big and to prevent cases where the tool getting killed would leave a partial file.

This seems like a very fragile check. Can you document the structure that you are trying to parse here? Is there any guarantee that this logic will continue to be valid?

The tool should correctly throw errors for permissions into tool exits, so you might only hit a fse if the file is missing.

Could you expand on this a little more, what string resources are required, what is the expected format, et cetera

Shouldn't the xml parser give you access to names/properties in a way that doesn't require looking at raw lines?

The idea is that I want to maintain the original formatting and comments in the file, and the xml parser consumes all of this and collapses it into a format-less xmldocument/xmlelement. This manual parsing is able to maintain any developer formatting/comments.

Moved to xml package based system.

nit: Alphabetize.

Should this parameter be @required?

This property can be null. If null, it will just use the default templates directory. I can document this.

Should there be a check here that this file exists, or is it already known to exist at this point?

Added an _invalidFiles system to report errors like this.

See: ErrorHandlingFileSystem.deleteIfExists

Can these be testWithoutContext?

If this yaml can be provided by users by hand, then there should be tests that the tool does an appropriate throwToolExit when it is malformed.

Same idea here. If settings.gradle is under user control, then it should not crash the tool (from the new code in this PR) if it is malformed, and there should be unit tests of that.

These methods can be made fairly standalone, by having each method individually return its inputs/outputs - then letting the caller be responsible for combining them.

So I actually want the class to handle the check result internally. I don't really want the caller to be handling the results of the validation directly since there are specific behaviors that should happen based off of the results of each check, which is handled by displayResults. Letting the caller combine/handle the check results directly can easily miss a lot of nuance and result in incorrect recommendations to the developer.

These checks are not intended be run independently of the overall validator class. Making them dependent on the class discourages/prevents this unintended use.