Skip to content

FontAssets from the build hook - #174860

Closed
mosuem wants to merge 15 commits into
flutter:masterfrom
mosuem:icontreeshaker
Closed

mosuem wants to merge 15 commits into
flutter:masterfrom
mosuem:icontreeshaker

Conversation

@mosuem

@mosuem mosuem commented Sep 3, 2025 •

Copy link
Copy Markdown
Contributor

Allows to add fonts via build hooks with https://pub.dev/packages/font_asset, see https://github.com/mosuem/font_asset_test as an example.

This now also calls the icon treeshaker via a link hook.

TODO:

  • Make adding via pubspec or build hook compatible
  • Allow for more fonts per family
  • Set up flutter config to hook input containing app.dill and other binaries.
  • Use @RecordUse instead of custom logic.

Long term: Unbundle icontreeshaker from flutter, remove fonts via pubspec adding.

Pre-launch Checklist

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.

@github-actions github-actions Bot added the tool Affects the "flutter" command-line tool. See also t: labels. label Sep 3, 2025
@Piinks

Piinks commented Nov 3, 2025

Copy link
Copy Markdown
Contributor

Greetings from stale PR triage! 👋
Is this change still on your radar?

@mosuem

mosuem commented Dec 30, 2025

Copy link
Copy Markdown
Contributor Author

@bkonyi @dcharkes @goderbauer wdyt? Just a proof of concept.

The next step would be to give IconData the @RecordUse annotation to replace the icon tree shaker with a build helper.

@mosuem mosuem changed the title Remove icon treeshaker and add fontasset Font treeshaking via package Jan 2, 2026

@dcharkes dcharkes left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Interesting!

I haven't looked at all the wiring, and if the caching works correctly with the targets etc.

This PR would benefit from an example (or better, an integration test as example).

I left some more remarks on the API design and naming.

Comment thread packages/flutter_tools/pubspec.yaml Outdated
ffi: 2.1.4
file: 7.0.1
flutter_template_images: 5.0.0
font_asset: 0.0.4

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should have been font_assets to be consistent with code_assets and data_assets.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah I noticed that afterwards as well.. 🙃


class FontHookAsset extends HookAsset {
FontHookAsset({
required super.file,

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This doesn't seem to mirror the way the yaml is set up. The yaml has more than one file per font.

https://docs.flutter.dev/cookbook/design/fonts#define-fonts-in-the-pubspec-yaml-file

Would it make more sense to make a FontFamilyAsset with a list of Fonts? In the current setup you'll end up repeating the family name. Especially if you end up writing a package:font_assets FontAsset object literal, it would make sense if it 1-to-1 translates to the yaml structure.

Also, I see a weight, but not an optional style?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I just went with a simple setup first to test it.

@mosuem

mosuem commented Jan 7, 2026 •

Copy link
Copy Markdown
Contributor Author

This PR would benefit from an example (or better, an integration test as example).

There is https://github.com/mosuem/font_asset_test, but I added that as an example here instead.

@github-actions github-actions Bot added a: desktop Running on desktop team-ios Owned by iOS platform team labels Jan 7, 2026
@bkonyi

bkonyi commented Jan 8, 2026

Copy link
Copy Markdown
Contributor

Sorry, not sure how this slipped past me!

I'm curious, do we plan on having developers specify their fonts in build hooks rather than the pubspec moving forward? Or do we plan on maintaining the current workflow of specifying fonts within the pubspec but generating and running a fonts build hook at runtime?

@dcharkes dcharkes changed the title Font treeshaking via package FontAssets from the build hook Jan 29, 2026
@dcharkes

dcharkes commented Jan 29, 2026 •

Copy link
Copy Markdown
Contributor

I believe a custom FontAsset might not be needed. The DataAssets could be enough. Flutter has https://api.flutter.dev/flutter/services/FontLoader-class.html that can load fonts with Future<ByteData>, and DataAssets can be loaded as such: https://api.flutter.dev/flutter/services/AssetBundle/load.html

The only advantage that the Flutter SDK knowing about FontAssets would have over the DataAssets + FontLoader is that you don't have to register your font in Dart code.

I think the way to make that work is to send a FontRegisterAsset from your package that declares a font to the flutter_framework package, and then have the flutter_framework package emit a DataAsset FontManifest.json and load that single json on startup. The only issue is that in JIT the build hooks are run in the order of dependencies instead of in reverse order. So there is no way to send such information from the awesome_fonts_flutter build hook to the flutter_framework build hook. The FontRegisterAsset type only exists temporarily between hooks. The DataAsset type is the only one that is bundled in the app bundle.

If we can make such pattern work, we don't need to add SDK support for custom asset types, they can be built on DataAssets. (So theoretically any code handling the bundling of ttfs and the font manifest could then be deleted from the flutter_tools code base.)

@mosuem

mosuem commented Jan 30, 2026

Copy link
Copy Markdown
Contributor Author

How would you merge fonts declared in the pubspec with fonts declared through the flutter_framework package?

@dcharkes

Copy link
Copy Markdown
Contributor

How would you merge fonts declared in the pubspec with fonts declared through the flutter_framework package?

Eventually, we'd phase those out? Theoretically. 😄

If we keep supporting them, we don't have to use font assets for the implementation of fonts from hooks. One small issue I can think of is that we wouldn't notice a conflict between built-in fonts and fonts loaded at runtime via data assets until runtime. Probably not a super often occurrence, so that might be acceptable.

If we want to phase support out, we could provide a hook that simply reads from the pubspec. Though users would still have to migrate. Actually the migration path should then maybe be that conflicts are not conflicts but that the new way overrides the oldway.

@Piinks

Piinks commented Mar 30, 2026

Copy link
Copy Markdown
Contributor

Greetings from triage! Is this a change we would like to move forward with? :)

@mosuem

mosuem commented Mar 31, 2026

Copy link
Copy Markdown
Contributor Author

I would like to move forward with this, I still believe it is the right path. I do not have the time right now unfortunately...

@Piinks

Piinks commented Jun 22, 2026

Copy link
Copy Markdown
Contributor

I would like to move forward with this, I still believe it is the right path. I do not have the time right now unfortunately...

Totally understand! This has made it back to stale triage. Is it something we need to leave open in the meantime?

@mosuem

mosuem commented Jun 24, 2026

Copy link
Copy Markdown
Contributor Author

Totally understand! This has made it back to stale triage. Is it something we need to leave open in the meantime?

That would be great!

@Piinks

Piinks commented Sep 2, 2026

Copy link
Copy Markdown
Contributor

Welcome back to stale triage! Should we close this for now? It has landed in stale triage many times now over the last year. If it is not actively being working on, perhaps we should close it. It can always be re-opened later.

@mosuem

mosuem commented Sep 3, 2026

Copy link
Copy Markdown
Contributor Author

Yeah it has unfortunately accumulated many merge conflicts by now, which is why I try to not let PRs get stale :/ Closing it, maybe someone else wants to tackle this sometime.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

a: desktop Running on desktop team-ios Owned by iOS platform team tool Affects the "flutter" command-line tool. See also t: labels.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants