[material_ui, cupertino_ui, infra] Support skipping golden files for the design migration

[Piinks]

This branches off of #10753 and strips it down to just the skipping comparator. This means when golden file testing is used with this version of flutter_goldens, matchesGoldenFile will return true in all environments without executing image comparison.
The goal of this PR is to join the material_ui and cupertino_ui mega-migration PR (cc @justinmc ) to disable golden file testing for now in material_ui and cupertino_ui so we can get a clearer signal from CI about any remaining blockers.
Full golden file testing support will likely land in #10753 as a separate step given the enormity of these PRs.

cupertino_ui and material_ui are set publish_to: none here, which is intentional. This allows us to split up these changes, and wait to publish until everything lands and is working as we want it to.

Pre-Review Checklist

• I read the Contributor Guide and followed the process outlined there for submitting PRs.
• I read the AI contribution guidelines and understand my responsibilities, or I am not using AI tools.
• I read the Tree Hygiene page, which explains my responsibilities.
• I read and followed the relevant style guides and ran the auto-formatter.
• I signed the CLA.
• The title of the PR starts with the name of the package surrounded by square brackets, e.g. [shared_preferences]
• I linked to at least one issue that this PR fixes in the description above.
• I followed the version and CHANGELOG instructions, using semantic versioning and the repository CHANGELOG style, or I have commented below to indicate which documented exception this PR falls under¹.
• I updated/added any relevant documentation (doc comments with ///).
• I added new tests to check the change I am making, or I have commented below to indicate which test exemption this PR falls under¹.
• All existing and new tests are passing.

If you need help, consider asking for advice on the #hackers-new channel on Discord.

Note: The Flutter team is currently trialing the use of Gemini Code Assist for GitHub. Comments from the gemini-code-assist bot should not be taken as authoritative feedback from the Flutter team. If you find its comments useful you can update your code accordingly, but if you are unsure or disagree with the feedback, please feel free to wait for a Flutter team member's review for guidance on which automated comments should be addressed.

Footnotes

1. Regular contributors who have demonstrated familiarity with the repository guidelines only need to comment if the PR is not auto-exempted by repo tooling. ↩ ↩²

[gemini-code-assist]

Code Review

This pull request introduces a new internal package, flutter_goldens, to support Skia Gold integration for golden image testing. It includes CI script updates, configuration for cupertino_ui and material_ui packages, and the core implementation of custom golden file comparators. Feedback highlights the need for proper URI-to-path conversion using the path package, correcting the Dart SDK version, fixing an incorrect import in material_ui, and ensuring safer YAML parsing.

[justinmc]

LGTM. After merging I can update my PR #11568 and then make sure it correctly skips the golden tests.

[justinmc]

Good call for now. I'll plan to remove this when we are ready to attempt to publish the first pre-release version.

[Piinks]

Ok thanks. Let me double check with Stuart before merging this.

[stuartmorgan-g]

Why are all of these any? That's almost guaranteed to cause breakage in the future.

[Piinks]

So this is the same as in flutter/flutter, and AFAIK it has not caused breakages. What should it be? The latest?

[stuartmorgan-g]

So this is the same as in flutter/flutter, and AFAIK it has not caused breakages.

flutter/flutter uses a repo-level workspace and checks in a lock file for it, so that every version of everything is exactly controlled in CI. This repo just uses standard pub resolution on a per-package basis, and (per Dart standards) doesn't check in lock files for packages.

So any in flutter/flutter is effectively "don't get in the way of the script that updates the lock file, which is where everything is actually controlled", whereas any here has the typical pub meaning of "Give me literally any version (which will in practice be the latest resolvable version every time it runs), and I don't care if it's a major version with breaking changes".

What should it be? The latest?

Typically we want packages depending on a ^ version for the latest major version, but I'm not sure what exactly this particular package needs. If you want to mostly match flutter/flutter's current behavior you could use a ^ range starting with whatever the flutter/flutter pubspec.lock version is for each package. If you want to exactly match flutter/flutter you could exactly pin every version here, but since we don't have a pub dependency roller for this repo that would mean a lot more manual work managing dependency versions over time.

[stuartmorgan-g]

Why is this using a prerelease version format?

[Piinks]

Probably because I copied most of this over from flutter/flutter for consistency. 😅
Let me fix this, thank you!

[Piinks]

Wait, yeah I thought I had checked this.. other packages here use the same format:

packages/packages/two_dimensional_scrollables/pubspec.yaml

Line 8 in 67ec0d3

sdk: ^3.9.0

packages/packages/go_router/pubspec.yaml

Line 9 in 67ec0d3

sdk: ^3.9.0

What should it be? I can send a separate PR to fix others if they are wrong too.

[Piinks]

Oh, unless it's the *-0?

[stuartmorgan-g]

Yes, X-0 means "any pre-release version of X". I would not expect us to need our tooling to support old prereleases.