Repository navigation
Support wildcard/globs in flutter: assets: YAML #27801
Description
See #4890 (comment).
I'd like to write:
flutter:
assets:
- assets/icons/**.png... instead of ...
flutter:
assets:
- assets/icons/country_flags/
- assets/icons/currency_codes/
- assets/icons/credit_card_vendors/
Activity
jonahwilliams commentedon Feb 12, 2019
Looked into this today.
The asset parsing code is in https://github.com/flutter/flutter/blob/master/packages/flutter_tools/lib/src/asset.dart#L524. The difficulty is that we cannot just start using Globs as
marnberg commentedon Feb 13, 2019
Thank you @jonahwilliams for looking into this. This is been on our watch list for a long time since we have images in assets/1.0x assets/2.0x and so on. Flutter picks the right asset listing the path without the scale factor but currently we have to list every asset in the yaml file. This is a big issue because we build multiple versions of our app with different assets.
ph55 commentedon Jan 18, 2020
Another use case.
Loading query language files. For example GraphQL files. They will usually will stick to it's library and won't be placed in one directory.
So pattern in this case would be any
.gqlfile inlibfolder:nimi0112 commentedon May 24, 2021
@matanlurey @jonahwilliams what is wrong with writing ?
triallax commentedon Aug 13, 2021
@nimi0112 I don't know about the others, but I use macOS, and I caught
.DS_Storefiles being put in assets.Fixes build
JaffaKetchup commentedon Oct 5, 2023
Bumping this 2 years later :)
As a workaround, what if there was a
flutter pub registerassetstool that read from a file supporting wildcards and auto generated the necessary pubspec?Conrad33 commentedon Jul 4, 2024
Another use case is with the new Asset transformation feature. For example something like:
doesn't work if the
imagesfolder contains anything other than.svgfiles.Instead we could do:
and only transform the assets we want to, ignoring any
.pngand.jpgfiles in the same folder.spydon commentedon Oct 8, 2025
The Dart workspaces definition now supports globs (dart-lang/pub#4680), it would be nice to have it consistent in the pubspec file so that assets also supports globs. (And if there are other places where globs also would make sense)
borzos6 commentedon Sep 2, 2026
Adding a data point: our asset tree is nested by category (
assets/characters/*,assets/backgrounds/*, etc.), and every new subfolder/file needs a manualpubspec.yamlentry. Two options would both solve it for us:assets/characters/*) — Support wildcard/globs influtter: assets:YAML #27801assets/**) — Include assets from a directory recursively #118635Current workaround is keeping folders flat to dodge the maintenance, which fights against organizing assets sensibly. Either fix removes real day-to-day upkeep for projects with any depth to their asset structure.
JaffaKetchup commentedon Sep 2, 2026
Hey, I'm happy to work on this (the glob approach). Trying to understand the background.
I've gone through the previous discussions, back to when the ability to add a whole directory at a time was added (#4890 & #16413 I think), and found this article written by the contributor then:
#4890 (comment) -> https://medium.com/flutter-community/contributing-to-flutter-part-3-4b96d924d8ba
And also #27801 (comment) from @jonahwilliams above.
So it looks like the bigger issue is around variants, which makes sense. And the other issue is that package:glob isn't directly compatible with the objects used in the tool.
The primary issue that the article author seemed to be concerned about was changing behaviour in future Flutter versions. I would think that this is less of a risk now everything's much more mature (please correct me if I'm wrong).
To just share the problem here:
Means two assets, 'hero.png' and 'landscape/hero.png', each with two variants. The author mentions he was concerned about future changes in behaviour meaning this becomes recognised differently.
But if this is instead declared just as:
Then we need to figure this out, rather than just having four different assets.
Now I think the solution that the author alludes to is using regex to say that any directory in the format:
[0-9]+\.[0-9]+xis a variant directory.
It is unclear to me whether the variant directory is always the last directory in the path (if present). I think this is the case though, which does make it slightly easier. I also don't know if an asset under a variant path can be referred to directly by its path if a specific variant is wanted - I guess it must be, for example in the case that the non-variant version is not declared.
The author says:
I don't quite understand what this is getting at. Surely it's just the build process' job to gather all the files and nothing else needs to change? And I've not seen any discussion about the second part - but yes, that would make the naive approach of using a regex to get resolution variant directories break. Perhaps a solution is to manually indicate for each declared path whether the last directory in the tree should be considered a variant - although that feels like a poor solution (and I can't see how to make that non-breaking).
It sounds like the original author did intend to perhaps come back and add it in at some point, but it looks like it never happened.
Can anyone confirm whether I've missed anything? Also the assets.dart file is quite large by the looks of it, so wondering if there were any existing plans to try and simplify or take it apart it if at all possible.