[FR]: Allow generated asset classes to implement custom interfaces (for Modular Architectures & Design Systems)

[Mairramer]

Is there an existing issue for this?

• I have searched the existing issues

Describe the problem

In modular Flutter architectures (Monorepos, micro-frontends, Design Systems), it is common for each package to generate its own assets.gen.dart using flutter_gen.

This creates a type interoperability issue between packages. For example, a Design System package may expose APIs that depend on generated asset types:

sealed class NavItem {
  String get title;
  SvgGenImage get icon;
}

If the consumer app passes its own generated asset (AppAssets.icons.home), Dart reports a type mismatch because each package generates a different SvgGenImage class.

Current workarounds are not ideal:

• Using dynamic or Object (losing type safety)
• Excessive import aliasing
• Creating wrapper classes for every asset

This becomes especially problematic in scalable modular architectures where assets need to move safely across package boundaries.

Describe the solution

Allow generated asset classes to optionally inject custom implements clauses and imports through pubspec.yaml.

Example configuration:

flutter_gen:
  assets:
    outputs:
      asset_class_implements: 'AppIconData'
      asset_class_import: 'package:design_system/utils/app_icon_data.dart'

Generated output:

import 'package:design_system/utils/app_icon_data.dart';

class SvgGenImage implements AppIconData {
  // ...
}

This allows packages to depend on shared abstractions instead of concrete generated classes:

abstract interface class AppIconData {}

sealed class NavItem {
  String get title;
  AppIconData get icon;
}

As a result, assets generated from different packages can interoperate safely while preserving compile-time type safety.

Additional context

Benefits of this approach:

• Fully opt-in with zero runtime overhead
• Improves interoperability between Design Systems and consumer apps
• Preserves strong typing across Monorepos and modular architectures
• Avoids falling back to dynamic or raw String asset paths
• Helps future AST-based tooling and asset tree-shaking strategies
• Aligns with Flutter’s abstraction patterns such as IconData

Example architecture:

Code of Conduct

• I agree to follow this project's Code of Conduct

[AlexV525]

When implement, you'll need to put extra @override in code generation, this still introduces configuration request to make users be able to declare which fields should be overrode. Otherwise, with this empty interface AppIconData, you are still losing the ability to obtain their actual fields.

Here is my quick thought: make an interface package named flutter_gen_interface, expose the XXXGenImage classes (when configured) so modular packages can depend on them which lying on the same inheritance tree.

[Mairramer]

When implement, you'll need to put extra @override in code generation, this still introduces configuration request to make users be able to declare which fields should be overrode. Otherwise, with this empty interface AppIconData, you are still losing the ability to obtain their actual fields.

Here is my quick thought: make an interface package named flutter_gen_interface, expose the XXXGenImage classes (when configured) so modular packages can depend on them which lying on the same inheritance tree.

I understand your point. I tested this approach before and it worked, but looking at it now, I agree that it’s probably not the best solution.

I’ll try the approach you suggested and verify the results.