Skip to content

Include assets from a directory recursively #118635

Open

Description

@cbatson

Greetings Flutter team & community,

I would like to re-open the discussion which started in #4890.

In particular, a mechanism to add asset files recursively would benefit my use case, and as evidenced by this comment, I suspect would benefit use cases of others.

My present use case is that I would like to embed many files into the app, so that I do not have to stand up a back end to host the files. This seems like a fairly typical desire.

However, not being able to recursively add assets is a hindrance.

I understand that

Use case

Add many files as assets, for example, when you'd prefer to bundle files with the app package rather than download them separately.

Proposal

I am mostly hoping to spark some conversation around this, although one possible way to do this given the legacy/constraints of variants would be to introduce a new pubspec.yaml key, analogous to assets, but which does not allow variants and will be capable of adding files recursively and/or by wildcard. Said new key could be named something like nonvariant_assets.

Thank you for your time.

Activity

  1. darshankawar commented on Jan 18, 2023

    @darshankawar
    Member

    Thanks for the report. Since the original issue is close and was an old one, I'll keep this issue open for team's attention if there's any changes in the approach since the last time this proposal was discussed.

  2. added
    toolAffects the "flutter" command-line tool. See also t: labels.
    a: assetsPackaging, accessing, or using assets
    c: proposalA detailed proposal for a change to Flutter
    and removed
    in triagePresently being triaged by the triage team
    on Jan 18, 2023
  3. damywise commented on Jan 26, 2023

    @damywise

    Honestly this feature would be so awesome in my use case. I'm developing a package. It is for a toolkit that basically generates completely different folder structure dynamically every time it saves a project, depending on the settings and the contents.

    This feature would completely remove the need of touching the pubspec.yaml every time the toolkit saves a project and regenerates the whole assets/* structure.

  4. added
    P3Issues that are less important to the Flutter project
    on Feb 23, 2023
  5. spydon commented on Feb 10, 2025

    @spydon
    Contributor

    Since games usually make very heavy use of assets (much more so than normal apps) I think this would deserve the GameDev tag, what do you think @wolfenrain?

  6. pcornelissen commented on Feb 10, 2025

    @pcornelissen

    The usecase is more likely for games, but larger applications may also suffer from this, when the icons are not in fonts, but seperate files or you have localized images of some kind etc.

    I was very surprised that something like that doesn't exist and globbing for asset definitions shouldn't be hard to implement, when you have control over the build steps

  7. Luckey-Elijah commented on Feb 10, 2025

    @Luckey-Elijah

    To avoid unintended consequences and confusion, I think an "opt-in" approach would be best. I believe that is the intent mentioned here #4890 (comment) in an early iteration of the folder bundling.

    Perhaps this could be enable in the flutter: entry in pubspec, allowing developers to explicitly enable the recursive asset bundling.

    For example:

    # pubspec.yaml
    flutter:
      recursive-bundling: true # doesn't really matter what the key is
      assets: [...]

    This approach avoids accidentally enabling the feature only via a vague glob-syntax mechanism (as mentioned here in #4890). Flutter developers still find asset declaration difficult, and some opt-in approach would prevent asset declaration from having other side effects.

  8. pcornelissen commented on Feb 10, 2025

    @pcornelissen

    it's not necessary to use switches for that, you could follow general solutions other frameworks usw and just use /foo/** for recursive resource folders

  9. EArminjon commented on Feb 10, 2025

    @EArminjon
    Contributor

    If we can use a syntax similar of the .gitignore one, it will be perfect.

  10. spydon commented on Feb 10, 2025

    @spydon
    Contributor

    I think the least confusing would be to use glob matching (just like the gitignore) so that it aligns with how it will work with the packages list under the workspace key (dart-lang/pub#4391). That would also not change the behavior of any current apps.

  11. added
    tool-still-validIssues that have been deemed still valid as part of the Flutter Tools issue cleanup initiative.
    on Jul 11, 2025
  12. qeepcologne commented on Sep 2, 2025

    @qeepcologne

    i am very desperate on this feature, especially if you need a lot of transformers, there is a lot of repetition.
    and i have another wish to add a flavor variable e.g.

        - path: assets/
          transformers:
            - package: vector_graphics_compiler
        - path: assets/login/
          transformers:
            - package: vector_graphics_compiler
        - path: assets/icons/
          transformers:
            - package: vector_graphics_compiler
        - path: assets/flags/
          transformers:
            - package: vector_graphics_compiler
        - path: assets/guide/
          transformers:
            - package: vector_graphics_compiler
        - path: assets/profile/
          transformers:
            - package: vector_graphics_compiler
        - path: assets/flavor1/
          flavors:
          - flavor1
          transformers:
            - package: vector_graphics_compiler
        - path: assets/flavor2/
          flavors:
          - flavor2
          transformers:
            - package: vector_graphics_compiler
        - path: assets/flavor3/
          flavors:
          - flavor3
          transformers:
            - package: vector_graphics_compiler
        - path: assets/flavor4/
          flavors:
          - flavor4
          transformers:
            - package: vector_graphics_compiler
    

    =>

        - path: assets/global/**
          transformers:
            - package: vector_graphics_compiler
        - path: assets/$flavor/**
          transformers:
            - package: vector_graphics_compiler
    
  13. jwmdykes commented on Sep 16, 2025

    @jwmdykes

    This is annoying for any app with a lot of content that you want to organize.

    For example I have a language learning app where the main content is "lessons" which are simple .yaml files organized into units, chapters and courses.

    Although it's possible to just make all the content a huge yaml file, it's much more sensible to organize it into folders and glob include all of the content in pubspec.yaml.

  14. telion2 commented on Jan 4, 2026

    @telion2

    New to flutter not new to development. This is very annoying. you create some subfolder put something in there. => Error. => Time wasted => research on how to recursively include all subfolders => more time wasted
    Why is this thread already 2 years old? Why not add a recursive include with assets/*
    This is already a manual opt-in (everyone can still use the old approach) and is very common if not default behavior.

  15. pcornelissen commented on Jan 5, 2026

    @pcornelissen

    Just to specify: common for subdirectory matches is /** so assets/** would be the right syntax to prevent accidental hits and enable you to add directories still one by one

  16. stan-at-work commented on Jan 23, 2026

    @stan-at-work
  17. borzos6 commented on Sep 2, 2026

    @borzos6

    Adding a data point: our asset tree is nested by category (assets/characters/*, assets/backgrounds/*, etc.), and every new subfolder/file needs a manual pubspec.yaml entry. Two options would both solve it for us:

    Current 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.

  18. JaffaKetchup commented on Sep 2, 2026

    @JaffaKetchup
    Contributor

    Can I propose merging this into #27801 (either this is a duplicate or a child)? Since a solution to that issue will solve this as well.

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    P3Issues that are less important to the Flutter projecta: assetsPackaging, accessing, or using assetsa: gamedevIssues related to game development with Flutterc: proposalA detailed proposal for a change to Flutterteam-toolOwned by Flutter Tool teamtoolAffects the "flutter" command-line tool. See also t: labels.tool-still-validIssues that have been deemed still valid as part of the Flutter Tools issue cleanup initiative.triaged-toolTriaged by Flutter Tool team

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions