Skip to content

flutter pub get regenerates Flutter platform tooling (ios/android) in non-Flutter pub workspace root packages #189550

Closed

Description

@ChaserVasya

Steps to reproduce

  1. Create a pub workspace where the root pubspec.yaml is a plain Dart package (no flutter: section):

    # pubspec.yaml
    name: root_pkg
    environment:
      sdk: ^3.11.0
    workspace:
      - apps/app
    # apps/app/pubspec.yaml
    name: app
    environment:
      sdk: ">=3.10.0"
    resolution: workspace
    dependencies:
      flutter:
        sdk: flutter
    // apps/app/lib/main.dart
    import 'package:flutter/material.dart';
    void main() => runApp(const MaterialApp(home: Scaffold()));
  2. At the workspace root, create an empty ios directory: mkdir ios.

  3. Run flutter pub get from the workspace root.

Expected results

ios/ stays empty. The root package has no flutter: dependency, so it's not a Flutter project and flutter pub get shouldn't write anything into it.

Actual results

flutter pub get populates ios/ with generated Flutter project files:

ios/Runner/GeneratedPluginRegistrant.h
ios/Runner/GeneratedPluginRegistrant.m
ios/Flutter/flutter_export_environment.sh
ios/Flutter/Generated.xcconfig
ios/Flutter/ephemeral/flutter_lldbinit
ios/Flutter/ephemeral/flutter_lldb_helper.py

ios/Flutter/Generated.xcconfig sets FLUTTER_APPLICATION_PATH to the workspace root itself — a package with no flutter: dependency, no lib/main.dart, no Xcode project.

Root cause

PackagesGetCommand.runCommand (packages/flutter_tools/lib/src/commands/packages.dart) iterates every name in PackageGraph.roots (from .dart_tool/package_graph.json) and unconditionally builds a FlutterProject for each:

for (final String workspaceRootName in graph.roots) {
  final Package? rootPackage = packageConfig[workspaceRootName];
  ...
  final FlutterProject project = FlutterProject.fromDirectory(globals.fs.directory(rootUri));
  ...
  await project.regeneratePlatformSpecificTooling(
    releaseMode: ignoreReleaseModeSinceItsNotABuildAndHopeItWorks,
  );

graph.roots includes the pub workspace root package itself, not just its Flutter app members. regeneratePlatformSpecificTooling (packages/flutter_tools/lib/src/project.dart) gates only on whether ios/android directories already exist on disk, not on whether the package declares a flutter: dependency:

Future<void> regeneratePlatformSpecificTooling({...}) async {
  return ensureReadyForPlatformSpecificTooling(
    androidPlatform: android.existsSync(),
    iosPlatform: ios.existsSync(),
    ...

So flutter pub get writes Flutter platform tooling into any ios/android directory sitting at a pub workspace root, whether or not that root package declares a flutter: dependency.

Flutter Doctor output

Flutter 3.41.1 • channel stable • https://github.com/flutter/flutter.git
Framework • revision 582a0e7c55 (5 months ago) • 2026-02-12 17:12:32 -0800
Engine • hash cc8e596aa65130a0678cc59613ed1c5125184db4 (revision 3452d735bd) (5 months ago) • 2026-02-09 22:03:17.000Z
Tools • Dart 3.11.0 • DevTools 2.54.1

Activity

  1. saurabh-mirajkar commented on Jul 16, 2026

    @saurabh-mirajkar
    Contributor

    @ChaserVasya Thanks for the detailed report! I was able to reproduce this behaviour on the latest stable release (3.44.6).

    Reproduction Details:

    • Behaviour: In a pub workspace whose root package is a plain Dart package (without a flutter: dependency), having an empty ios/ directory at the workspace root causes flutter pub get to generate Flutter platform tooling under the workspace root.
    • Affected platforms: I observed the exact same behaviour with empty android/, macos/, and linux/ directories.
    • Unaffected platforms: Empty web/ and windows/ directories were not populated during testing (tested on macOS 26.5.2).

    Labelling and routing this for further investigation.

  2. added
    toolAffects the "flutter" command-line tool. See also t: labels.
    has reproducible stepsThe issue has been confirmed reproducible and is ready to work on
    team-toolOwned by Flutter Tool team
    and removed
    in triagePresently being triaged by the triage team
    on Jul 16, 2026
  3. added
    P2Important issues not at the top of the work list
    triaged-toolTriaged by Flutter Tool team
    on Aug 4, 2026
  4. github-actions commented on Aug 19, 2026

    @github-actions

    This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of flutter doctor -v and a minimal reproduction of the issue.

  5. locked as resolved and limited conversation to collaborators on Aug 19, 2026
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

    P2Important issues not at the top of the work listhas reproducible stepsThe issue has been confirmed reproducible and is ready to work onteam-toolOwned by Flutter Tool teamtoolAffects the "flutter" command-line tool. See also t: labels.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