Skip to main content

Build & Export Failures Caused by Package Conflicts

Written by Henry
Updated over a week ago

Build issues can occur when a FlutterFlow project includes deprecated packages, incompatible versions, or dependency conflicts between packages added through Custom Code, Marketplace components, or private/unpublished sources.

This guide explains:

  • How dependency conflicts happen

  • How to fix them directly in FlutterFlow

  • How to safely add private/unpublished packages

  • What to do when a fix requires code export

Applies to

This article applies when:

  • A project fails to Run, Build, or Export Code

  • A build log mentions:

    • “Version solving failed”

    • “Because package X depends on Y…”

    • “Duplicate definition / invalid type”

  • A package is required in a Custom Widget or Custom Action but build fails

  • A package is imported using private/unpublished sources (Git or private package hosting)

Why this happens (Common Causes)

1) Package version conflicts

FlutterFlow adds dependencies into the project build automatically. If multiple dependencies require incompatible versions, the Flutter package resolver cannot select a valid set.

2) Transitive / Subpackage dependency conflicts

Even if only one package was added manually, that package may depend on subpackages internally (transitive dependencies).

Example:

  • You add Package A

  • Package A requires intl: ^0.18.x

  • Another package (or FlutterFlow tooling) requires intl: ^0.17.x

    ➡️ The build fails because both versions cannot exist together.

3) Deprecated or discontinued packages

If a dependency is no longer maintained, it may break with Flutter SDK updates or web compilation.

4) Private / unpublished packages

Private packages require special configuration (e.g., Git dependencies or authentication). If not configured correctly, exports and builds can fail.

Step-by-Step: Fixing Dependency Issues in FlutterFlow

Step 1 — Review your dependencies in FlutterFlow

Go to:

Project → App Settings → Custom Code → Pubspec Dependencies

Check for:

  • Packages with outdated versions

  • Exact pins (example: intl: 0.17.0) that should be flexible

  • Versions with build metadata (^1.2.3+1) — replace these with valid semver constraints: ^1.2.3

FlutterFlow requires standard semver constraints. Build metadata (the +... part) can break build/export in some cases.

Step 2 — Identify where the dependency came from

Dependency issues are often introduced by:

  • Marketplace / Community components

  • Custom Widgets

  • Custom Actions

  • External/private packages

To identify the source:

  • Review Marketplace items used in the project

  • Review Custom Widget / Custom Action imports (look at import statements)

  • Check recent changes to dependencies or custom code

✅ If a single component introduces the dependency, remove it temporarily and rebuild to confirm.

Step 3 — Resolve conflicts by aligning versions

If the build log mentions a version-solving failure, it usually means a conflict between package versions.

Recommended approach inside FlutterFlow:

  1. Find the conflicting package in the error log (example: intl, http, firebase_core).

  2. In Pubspec Dependencies, update the version constraint so:

    • It matches the version required by most packages

    • It is compatible with FlutterFlow’s tooling

  3. Save and rebuild

Avoid using exact pins unless required. Flexible constraints improve compatibility.

Step 4 — Handling transitive dependency (subpackage) conflicts

If you didn’t add a conflicting package directly, it likely arrived as a transitive dependency. Examples: intl, collection, meta, js, flutter_web_plugins.

✅ In FlutterFlow, the best way to fix this is:

  • Adjust the top-level version in Pubspec Dependencies to align with the dependency tree.

    Brief example (inline): if the build reports intl conflicts between ^0.17.0 and ^0.18.0, open Project → App Settings → Custom Code → Pubspec Dependencies, add or edit intl with ^0.18.0, save, and rebuild. This tells the resolver to prefer the 0.18.x line; if all consumers accept that range the resolver will find a consistent set.

  • Replace the dependency that introduced the conflicting subpackage (if needed).

Adding Private / Unpublished Packages in FlutterFlow

FlutterFlow supports adding unpublished or private packages through the Custom Code dependency settings.

Go to: Project → App Settings → Custom Code → Pubspec Dependencies

Private/unpublished packages are typically added using:

  • Git-based dependencies

  • Private repositories

  • Authentication credentials (where required)

Possible use cases

  • Using a different branch of a package: Test or use features available only on a specific branch (for example a feature branch that has not been released on pub.dev).

  • Forked version for customizing features: Use a fork when custom changes or fixes are needed that the original maintainer has not addressed.

  • Private packages for internal use: Include internal or proprietary Flutter libraries that cannot be published publicly but are required by the app.

How to declare (editor example)

# Public git repo my_private_package:   git:     url: <https://github.com/my-org/my_private_package.git>     ref: v1.0.0  # SSH-based repo my_private_package:   git:     url: git@github.com:my-org/my_private_package.git     ref: main

Important considerations

  • Repository access: Ensure the FlutterFlow build/export environment can authenticate to private repositories. If it cannot, export and build locally with the required credentials.

  • Credentials & authentication: Use SSH keys, deploy keys, or personal access tokens according to best practice. Do not embed credentials in plaintext URLs.

  • Transitive conflicts: Private packages can introduce transitive dependencies; align top-level versions as needed or export and apply overrides if required.

For full instructions and examples, see:

https://docs.flutterflow.io/concepts/custom-code#using-unpublished-or-private-packages

When exporting code is required

Some dependency fixes cannot be applied within FlutterFlow because they require:

  • dependency_overrides

  • patched / forked packages

  • advanced resolver control

  • custom auth credentials for private repositories that cannot be configured in-editor

In these cases:

  1. Export the project

  2. Update pubspec.yaml locally

  3. Run:

flutter pub get flutter build <platform>

Common error messages & what they mean

“Version solving failed”

A dependency version conflict (often transitive).

✅ Fix by aligning dependency versions or replacing the conflicting package.

“Package X depends on Y version …”

Two dependencies require incompatible versions of the same package.

✅ Fix by selecting compatible versions or removing one package.

“InvalidType / Duplicate definition”

Usually a namespace/type conflict (often web builds).

✅ Fix by removing conflicting packages or switching to a maintained alternative.

“Failed to export code. Unexpected error…”

Often caused by invalid dependency formatting, incompatible custom code, or a Marketplace item misconfiguration.

✅ Fix by removing the component or correcting dependency versions.

Best Practices (to avoid future dependency failures)

  • Prefer maintained packages (avoid deprecated/discontinued packages)

  • Avoid exact pins unless necessary

  • Do not include +build metadata in version constraints

  • Introduce one Custom Code dependency at a time and rebuild

  • Keep Marketplace components updated and verify package health before adoption

  • For private packages, ensure repository access requirements are met

If issues persist

Before asking for help, collect:

  • Full build log (copy/paste text)

  • Screenshot of App Settings → Custom Code → Pubspec Dependencies

  • List of Marketplace components used

  • Whether any private packages were added (and how)

Next steps & support

If the editor steps do not resolve the issue, gather the artifacts listed above and open a support request. If exporting is required, include pubspec.yaml and pubspec.lock from the exported project.

Did this answer your question?