Reusable Action Flow (App Action Component) navigating to a page in a dependency library fails to compile: missing library `index.dart` import in generated `actions.dart`

[vdevc]

Can we access your project?

• I give permission for members of the FlutterFlow team to access and test my project for the sole purpose of investigating this issue.

Current Behavior

When a reusable Action Flow (an App Action Component, i.e. an action defined independently of any page and invoked elsewhere as a callback/Library Value Action) contains a Navigate action targeting a page that belongs to a dependency library, the generated code in lib/actions/actions.dart fails to compile.

The generated file correctly imports the dependency library's schema/enums and API calls files, and also correctly imports the library's own actions/actions.dart file (used when the reusable Action Flow calls an Action Component/function exposed by the library, e.g. a "get data" style action). However, it does NOT import the library's root index.dart barrel file with its $<library_alias> prefix, which is required to resolve <library_alias>.<PageWidget>.routeName (or .routePath, or direct instantiation) used by the Navigate action.

This produces a compile error such as:

lib/actions/actions.dart:XXX:Y: Error: Undefined name '$<library_alias>'.
    $<library_alias>.<SomePageWidget>.routeName,
    ^^^^^^^^^^^^^^^^^^^^^^^

Note that the exact same reference pattern ($<library_alias>.<SomePageWidget>.routeName) compiles and works correctly when it appears inside a normal page widget file (e.g. lib/pages/.../some_page_widget.dart) rather than inside the shared actions.dart file. The project configuration itself is correct: the Navigate action's YAML uses the standard cross-library reference (dependencyProjectId set on both widgetClassNodeKeyRef and pageNodeKeyRef), identical to references that resolve correctly elsewhere in the same project. This rules out a project misconfiguration; the gap is specifically in the import-generation logic used for the shared reusable-actions file.

Forcing a full project resync (sync_project with force: true via the FlutterFlow MCP/CLI tooling) and re-triggering code generation from FlutterFlow Desktop does not resolve the issue; the import remains missing across multiple regenerations.

Expected Behavior

When a reusable Action Flow / App Action Component contains a Navigate action targeting a page that belongs to a dependency library, FlutterFlow should generate the required import 'package:<library_package>/index.dart' as $<library_alias>; statement in lib/actions/actions.dart (or wherever that reusable action's code is generated), the same way it already does for page widget files that reference library pages directly.

Steps to Reproduce

1. Create a main project with at least one FlutterFlow Library added as a Project Dependency.
2. In the Library project, create a page (e.g. LibraryPageA).
3. In the main project, create a reusable Action Flow that is NOT attached to any specific page's widget tree (i.e. an App Action Component, created and invoked as a standalone/global action, such as a Library Value Action / completion callback passed into a component).
4. Inside that reusable Action Flow, add a "Navigate To" action targeting LibraryPageA (the page from the dependency library), optionally passing parameters.
5. Save, and generate/download the code (or build directly from FlutterFlow Desktop).
6. Inspect lib/actions/actions.dart: the function generated for the reusable Action Flow contains a call such as context.pushNamed($<library_alias>.LibraryPageAWidget.routeName, ...), but the top of the file has no import 'package:<library_package>/index.dart' as $<library_alias>; statement.
7. Attempt to build the app (flutter build ios / flutter build apk, or build directly from FlutterFlow Desktop). The build fails with Error: Undefined name '$<library_alias>'.
   As a control/comparison step: add a Navigate action targeting the same library page (LibraryPageA) directly inside a page widget's own action chain (e.g. an ON_TAP action on a button placed on a page in the main project, not inside a standalone reusable Action Flow). This compiles successfully and the corresponding page widget file correctly contains the $<library_alias> import. This isolates the bug to code generation for standalone/reusable Action Flows (App Action Components) specifically, as opposed to page-scoped action chains.

As a second control step: add, to the same reusable Action Flow file (actions.dart), a different reusable Action Flow that calls an Action Component/function exposed by the dependency library (not a page navigation) — this compiles successfully and correctly generates the corresponding import 'package:<library_package>/actions/actions.dart' as <library_alias>_action_blocks; line. This confirms the import-generation gap is specific to library page references (index.dart barrel), not to cross-library references in actions.dart in general.

Reproducible from Blank

• The steps to reproduce above start from a blank project.

Bug Report Code (Required)

ITFfksrl25NOseEA0a6JccdojSosJVscTIMziNZ+exUbfaL1BuwTeMzOZVtvZPWnaVNfeGGJuHw0/8rxj87LEPknAzqBba5R1pZMUxXOe2inVqXTBamWRkQlQNxUCnab0LbQoBB5PfV1cWQd2l+POOiUZ3PDFOu/Zwh9f6PHaOI=

Visual documentation

Environment

- FlutterFlow version: 7.0.33
- Platform: MacOS
- Browser name and version:
- Operating system and version affected: Sequoia 15.7.3

Additional Information

No response

[Juansarmi]

Hi! Sorry to hear you're experiencing this issue.

Unfortunately, I'm not able to reproduce the error on my end.

Because your project is quite large, it's very difficult to identify and isolate the root cause of the issue. Could you please try reproducing the problem in a new blank project? If you're able to reproduce it there, please send me the bug report code from that new project so I can investigate further.

Thank you, and I look forward to hearing from you!

Best regards