[google_fonts] Update the font generator to exclude variable font entries when a static entry of the same weight and style exists

[guidezpl]

#10713 accidentally introduced duplicate variable fonts for 400 weight fonts, an issue only discovered through https://pub.dev/packages/google_fonts/score, because this repo's analysis options exclude generated files. Using 7.0.0 would cause the variable font variant to be used for 400 weight, a non-issue, apart from the typically larger font size.

With this PR:

• Updated the font generator to exclude variable font entries when a static entry of the same weight and style exists, keeping variable fonts only if no static equivalent is present.
• Updated font proto and regenerated Dart parts.
• Renamed generated files from .g.dart to .dart for google_fonts_all_parts and all font part files. Updated generator, template, and main library to use the new file extensions, and added some missing public API documentation.
• Prepares for future explicit variable font support and improves font selection consistency.

Fixes flutter/flutter#180634

Related to flutter/flutter#174575 and flutter/flutter#174567

Pre-Review Checklist

• I read the Contributor Guide and followed the process outlined there for submitting PRs.
• 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 updated pubspec.yaml with an appropriate new version according to the pub versioning philosophy, or I have commented below to indicate which version change exemption this PR falls under¹.
• I updated CHANGELOG.md to add a description of the change, following repository CHANGELOG style, or I have commented below to indicate which CHANGELOG exemption 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 updates the font generator to prevent duplicate font entries by excluding variable fonts when a static equivalent with the same weight and style already exists. This is achieved by adding isVf and postScriptName fields to the Font protobuf message, regenerating the necessary Dart files, and implementing filtering logic in the generator. My review focuses on the new filtering logic, for which I've suggested a more efficient and readable implementation that avoids a nested loop.

[guidezpl]

@stuartmorgan-g I added @TestOn('vm') to the test due to proto usage, but the web tests still run, can you please advise?

[stuartmorgan-g]

an issue only discovered through https://pub.dev/packages/google_fonts/score, because this repo's analysis options exclude generated files

Since the files are generated by the package itself, we could change them to not use the .g suffix, and just make it a requirement that the generation follows all of our own style. Given this issue, that seems like it's probably the better option.

[guidezpl]

an issue only discovered through https://pub.dev/packages/google_fonts/score, because this repo's analysis options exclude generated files

Since the files are generated by the package itself, we could change them to not use the .g suffix, and just make it a requirement that the generation follows all of our own style. Given this issue, that seems like it's probably the better option.

For sure, can do that. But what of the question about failing tests?

[stuartmorgan-g]

@stuartmorgan-g I added @TestOn('vm') to the test due to proto usage, but the web tests still run, can you please advise?

It looks to me like it's failing earlier than trying to run them; it's not able to even compile the file. It looks like using path-based includes that reach outside of test/ may be an issue? I'm not familiar enough with the internals of how Dart resolves imports to know what specifically is going wrong there.

[stuartmorgan-g]

Stepping back slightly, can you write a test that tests that the generated files have the property we want, rather than directly testing the implementation of the generator?

[guidezpl]

Stepping back slightly, can you write a test that tests that the generated files have the property we want, rather than directly testing the implementation of the generator?

We can't test the API directly since Dart always returns the last value if a map contains duplicates. So that leaves clunky string matching or using the ast package to check for duplicates. Which is preferable do you think, or is there another way?

[stuartmorgan-g]

Is the core thing we want to test just "there aren't duplicate entries with the same key", or is it "we removed the right duplicate"?

If it's the former, the best option is probably to make the filename change; we don't need to test things that the analyzer will catch. If it's the latter, could we pick some specific known values to test in the output (to see that it's the static version), with a comment explaining how to pick a new test value if the test starts failing after running the generator due to font changes?

[guidezpl]

Is the core thing we want to test just "there aren't duplicate entries with the same key", or is it "we removed the right duplicate"?

If it's the former, the best option is probably to make the filename change; we don't need to test things that the analyzer will catch. If it's the latter, could we pick some specific known values to test in the output (to see that it's the static version), with a comment explaining how to pick a new test value if the test starts failing after running the generator due to font changes?

Former is covered now by file rename. For the latter, I suppose I'm fairly confident in the correctness right now. I also added some debugging to the generator to clarify what's happening

Success! Using https://fonts.gstatic.com/s/f/directory011.pb
Found 1875 font families, composed of 7270 static variants and 688 variable variants.
After deduplication: composed of 7270 static variants and 0 variable variants.

[guidezpl]

ignoring these because all types are the same function type with a long list of arguments (e.g. https://pub.dev/documentation/google_fonts/latest/google_fonts/GoogleFonts/aBeeZee-constant.html), which makes for quite ugly code.

[stuartmorgan-g]

SGTM.

I'm pretty sure the reason I renamed the files as part of the import was that I started to fix analyzer issues, ran into this, realized it would be awful, and then was going to add ignores but realized that since it was generated code we could just treat it like we do other generated code. Given that we now have a reason not to do that, the ignores strike the right balance.

[guidezpl]

yeah, that makes sense!