[CI] Update deps script

[Piinks]

• Unblocks [material_ui] Batch release #12423

Fixes a Pub version solver failure during release PR testing (make-deps-path-based) for co-dependent packages (specifically material_ui and cupertino_ui).

When creating a release PR for material_ui (e.g., release-material_ui-0.0.3+1), the make-deps-path-based CI step failed during flutter test on packages/cupertino_ui with the following Pub version solver error:

Resolving dependencies in `./example`...
Because every version of material_ui from path depends on cupertino_ui from hosted and cupertino_ui_examples depends on cupertino_ui from path, material_ui from path is forbidden.
So, because cupertino_ui_examples depends on material_ui from path, version solving failed.
Failed to update packages.

material_ui and cupertino_ui share an asymmetric co-dependency in the repository:

• material_ui has a direct dependency on cupertino_ui (dependencies: cupertino_ui: ^0.0.3).
• cupertino_ui has a dev dependency on material_ui (dev_dependencies: material_ui: ^0.0.2).

When make-deps-path-based --target-dependencies=material_ui runs:

1. make-deps-path-based adds dependency_overrides: material_ui: {path: ../material_ui} to cupertino_ui/pubspec.yaml and cupertino_ui/example/pubspec.yaml.
2. cupertino_ui/example depends directly on cupertino_ui (path: ..).
3. material_ui (from path) depends on cupertino_ui: ^0.0.3 (from hosted pub.dev).
4. Without cupertino_ui in cupertino_ui/example's dependency_overrides, Pub detects cupertino_ui sourced from path (in cupertino_ui_examples) and hosted (in material_ui), causing Pub's version solver to reject the resolution graph.

Updated make-deps-path-based (script/tool/lib/src/make_deps_path_based_command.dart):

When _addDependencyOverridesIfNecessary recursively updates example apps of a package (for (final RepositoryPackage example in package.getExamples())), it now explicitly includes the parent package itself in the local package mapping and additionalPackagesToOverride.

This ensures cupertino_ui/example/pubspec.yaml receives a path override for its parent package (dependency_overrides: cupertino_ui: {path: ...}) alongside the target package override (material_ui: {path: ...}). Consequently, Pub solver resolves both local path dependencies cleanly without requiring recursive dependency expansion (thereby preserving the safety net of --target-dependencies).

---

Why cupertino_ui Has a dev_dependency on material_ui

cupertino_ui declares material_ui in its dev_dependencies because multiple files across cupertino_ui/lib/src/ (e.g., text_field.dart, dialog.dart, scrollbar.dart, theme.dart) use Dart @docImport directives referencing Material design widgets in public API documentation:

/// @docImport 'package:material_ui/material_ui.dart';

Per Dart doc guidelines, packages referenced in @docImport must be declared in dev_dependencies so static analysis and dartdoc can resolve the cross-referenced symbols.

---

Didn't we fix this last week?

• Aug 4, 09:06 AM (material_ui 0.0.3 release Sync release-material_ui-0.0.3 to main #12352): Both packages still used Dart Workspaces (resolution: workspace). Under Dart Workspaces, Pub dependency resolution was handled at the top-level workspace root, hiding the Pub solver conflict.
• Aug 4, 12:44 PM (PR [material_ui and cupertino_ui] Remove workspaces and fix CI #12351): PR [material_ui and cupertino_ui] Remove workspaces and fix CI #12351 landed to unblock cupertino_ui 0.0.3 by removing Dart workspaces from cupertino_ui and material_ui.
  • When releasing cupertino_ui (targetDependencies=cupertino_ui), material_ui got path overrides for cupertino_ui. Since cupertino_ui didn't depend on a third package pulling hosted cupertino_ui, cupertino_ui's release succeeded.
  • However, when releasing material_ui (targetDependencies=material_ui), material_ui's direct dependency on cupertino_ui caused cupertino_ui/example to fail.
• Aug 10 (material_ui 0.0.3+1 release [material_ui] Batch release #12423): This was the first release attempt of material_ui since Dart workspaces were removed, exposing the non-workspace Pub solver requirement.

Pre-Review Checklist

• I read the Contributor Guide and followed the process outlined there for submitting PRs.
• I read the AI contribution guidelines and understand my responsibilities, or I am not using AI tools.
• I read the Tree Hygiene page, which explains my responsibilities.
• I read and followed the relevant style guides and ran the auto-formatter.
• I signed the CLA.
• The title of the PR starts with the name of the package surrounded by square brackets, e.g. [shared_preferences]
• I linked to at least one issue that this PR fixes in the description above.
• I followed the version and CHANGELOG instructions, using semantic versioning and the repository CHANGELOG style, or I have commented below to indicate which documented exception this PR falls under¹.
• I updated/added any relevant documentation (doc comments with ///).
• I added new tests to check the change I am making, or I have commented below to indicate which test exemption this PR falls under¹.
• All existing and new tests are passing.

If you need help, consider asking for advice on the #hackers-new channel on Discord.

Note: The Flutter team is currently trialing the use of Gemini Code Assist for GitHub. Comments from the gemini-code-assist bot should not be taken as authoritative feedback from the Flutter team. If you find its comments useful you can update your code accordingly, but if you are unsure or disagree with the feedback, please feel free to wait for a Flutter team member's review for guidance on which automated comments should be addressed.

Footnotes

1. Regular contributors who have demonstrated familiarity with the repository guidelines only need to comment if the PR is not auto-exempted by repo tooling. ↩ ↩²

[gemini-code-assist]

Code Review

This pull request updates MakeDepsPathBasedCommand to recursively resolve and include local in-repo dependencies of target packages using a queue-based approach, preventing pub version solving conflicts. It also ensures a package's own directory is included in the overrides and updates the corresponding tests. The review feedback suggests refining the federated package matching logic to prevent overly broad matches and using package.parsePubspec().name instead of package.directory.basename for more robust package name retrieval.

[justinmc]

LGTM, thanks for the detailed PR description. @stuartmorgan-g should also review.

[stuartmorgan-g]

1. Transitive In-Repo Dependency Traversal: _findLocalPackages now recursively expands in-repo dependencies of target packages so that co-dependent local packages are included in localDependencies.

I really don't think we should do this as a general approach; instead I would highly recommend that this portion of the walk be restricted to dev dependencies.

From a high level, here's the thing that the pathified check was added to avoid (which happened not infrequently before):

1. Package A in the repo depends on package B in the repo.
2. Package B is updated in some way that unexpected breaks package A (e.g., in a recent case we tried adding an enum value, not realizing that Dart had changed to make non-exhaustive enum handling a compile error)
3. Package B passes its own checks, so lands and is published
4. On the next run that happens to involve package A, it fails for reasons that have nothing to do with the PR where it fails (out-of-band breakage)
   • Also, all clients are broken the same way, and we probably have to do a retraction.

If you over-pathify, it's very easy for someone to accidentally bypass the safety added by the pathified check and publish something that breaks clients, because you are no longer testing the same combination of packages that clients will run when B is published.

For dev dependencies it should be fine since those don't affect clients, but changing non-dev dependencies would regress the safety net.

[Piinks]

Ok thank you. This is very helpful. I will update to only cover dev dependencies.

[Piinks]

Ok, I have updated this.
I removed the recursive dependency walking entirely so the tool remains non-recursive and preserves the safety net. Instead, when _addDependencyOverridesIfNecessary updates example apps for a package, it now explicitly includes the parent package in the local packages lookup and additionalPackagesToOverride.

I also made sure we have test coverage for both aspects, one to validate that example apps receive path overrides for both the target dependency (material_ui) and their own parent package (cupertino_ui), resolving pub solver dependencies cleanly. And the other to ensure it does not recursively override dependencies of target packages to preserve that safety net.

PTAL. :)

I'll update the PR description as well.

[stuartmorgan-g]

LGTM with one nit

[stuartmorgan-g]

Could you add an inline comment on parentPackgaeName being here? Since foo/example always depends on foo by path, it's really non-obvious why this would be necessary outside the context of someone reviewing this PR :)

Maybe something like:

// Add an override to the parent package in case a transitive dependency has a dependency on it,
// since that (non-path) dependency would conflict with the path-based dependency in the example.

[Piinks]

Excellent! On the way. Thank you!

[auto-submit]

autosubmit label was removed for flutter/packages/12427, because - The status or check suite Dashboard Checks has failed. Please fix the issues identified (or deflake) before re-applying this label.

[auto-submit]

autosubmit label was removed for flutter/packages/12427, because - The status or check suite Dashboard Checks has failed. Please fix the issues identified (or deflake) before re-applying this label.