Provide an API in the Flutter tool to make it extensible

@christopherfujino

Edit by @christopherfujino a design doc for this proposal is at https://flutter.dev/go/flutter-tool-extension-api

Right now, the Flutter tool is somewhat extensible by wrapping main() in a project-specific main() method, that uses combinations of AppContext.run() and the top-level run() function to override certain behaviors of the tool:

flutter/packages/flutter_tools/lib/runner.dart

Line 29 in d675bbb

Future<int> run(

for instance, the code would look something like this:

import 'package:flutter_tools/runner.dart' as runner;
import 'package:flutter_tools/src/base/context.dart';
import 'package:flutter_tools/src/commands/config.dart';
import 'package:flutter_tools/src/commands/daemon.dart';
import 'package:flutter_tools/src/commands/devices.dart';
import 'package:flutter_tools/src/commands/logs.dart';
import 'package:flutter_tools/src/runner/flutter_command.dart';

Future<Null> main(List<String> args) async {
  final Map<Type, Generator> overrides = await _getProjectSpecificOverrides();

  await context.run(
    overrides: overrides,
    body: () {
      return runner.run(args, <FlutterCommand>[
        new _ProjectSpecificAttachCommand(),
        new ConfigCommand(),
        new DaemonCommand(),
        new DevicesCommand(),
        new _ProjectSpecificDoctorCommand(),
        new LogsCommand(),
        new _ProjectSpecificRunCommand(),
      ]);
    },
  );
}

The problem with this is that in order to accomplish this behavior, the project has to reach into implementation files in flutter_tools, as well as the fact that this is all undocumented because it's not an official API.

There are a growing number of use cases for making the Flutter tool extensible, such as allowing project to:

wire up code generation as part of their build (and likewise for hot reload)
wire up C/C++ compilation as part of their build (moreso when Design and implement Dart VM FFI dart-lang/sdk#34452 and Support integrating with C/C++ in plugin framework #7053 are implemented)
Support a different enumeration of device types (e.g. desktop embedders)
Expose a Flutter tool "plugin", such that other Flutter projects can customize their developer experience just by installing a set of plugins

For a targeted set of use cases, we should expose an API in the Flutter tool for how such projects could import & extend the tool.

Are #9870, #16204, #13834 duplicates/related?

Yep! I closed the others to centralize on this one since it provides the most detail in the description.

I'm currently working on integration between the flutter tool and build_runner so that code generation can be fully managed by the tool. That means generators are run at appropriate times (before hot reload, analyze, tests) and knowledge of builders is incorporated into the tool and messaging.

There is a lot of ground to cover in terms of making sure it is performant and works with all of the existing flutter commands. During this time, it will be be available as an "experiment" behind a flag for developers interested in trying it out.

If you're interested in support for code generation please follow (and thumbs up) #27141

One concrete use-case for this API: allow plugging into Bazel.

@stuartmorgan

This came up again during discussions about Linux run/build support with @stuartmorgan. The idea is to provide minimal Dart APIs and then support a simplified plugin interface. The tool could then execute each plugin in an isolate and communicate via json.

Example:
my_app/pubspec.yaml

tool_plugin:
  - linux_device_clang # refers to a pub package, no version since that is constrained via the tool

We provide a minimal set of interfaces that can be implemented to define a device & workflow. These could be defined in flutter_tools/lib/api. Alternatively, we could define a separate pub package that the flutter_tool uses, or figure out distribution later.

class Plugin {
  Future<List<Device>> get devices;
  
  Future<String> get doctor;
}

// Minimal version of existing device type.
class Device {
  ...
}

A user defined plugin might require some additional configuration, from which we can generate an entrypoint.

linux_clang_device/tool_plugin.yaml

plugin: lib/linux_clang_device.yaml
name:  linuxToolPlugin

When running the tool, we check for plugins and run generation if it hasn't run before. Then on certain commands we invoke methods across the isolate boundary using a JSON api which we control/generate via the entrpoint generation. The generated code would be responsible for turning the json into typed/documented method calls

flutter_tools                                linux_clang_device
`flutter devices`               ->           {"method":  "getDevices"}
                                <-           {"id": "some_id"}
`flutter run -d some_id         ->           {"method": "run", "artifactLocations": [], "projectDirectory": ...}

so my use case would be to invoke CLI command, e.g.:

echo "Hello world"

before compilation begins/hot reloads

This ticket #9870 seemed more like a right place to ask for it, but got closed as a duplicate 🤷‍♂

This was sent to me on Twitter as something that would be neat to support from VS Code:

https://pub.dev/packages/device_preview

It would be hard to do from the IDE (currently it requires code changes or its own entry point, and modifying/writing files from the IDE would be clunky), but I wonder if it'd fit in here (it'd also work for other IDEs and command line users if wired up here).

@bkonyi

This issue is assigned to @bkonyi but has had no recent status updates. Please consider unassigning this issue if it is not going to be addressed in the near future. This allows people to have a clearer picture of what work is actually planned. Thanks!

@bkonyi

This issue is assigned to @bkonyi but has had no recent status updates. Please consider unassigning this issue if it is not going to be addressed in the near future. This allows people to have a clearer picture of what work is actually planned. Thanks!

@bkonyi

This issue was assigned to @bkonyi but has had no status updates in a long time. To remove any ambiguity about whether the issue is being worked on, the assignee was removed.

@bkonyi

This issue is assigned to @bkonyi but has had no recent status updates. Please consider unassigning this issue if it is not going to be addressed in the near future. This allows people to have a clearer picture of what work is actually planned. Thanks!

This is actively being investigated, but nothing to report yet.

Navigation Menu

Repository navigation

Provide an API in the Flutter tool to make it extensible #25377

28 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Provide an API in the Flutter tool to make it extensible #25377

Description

Activity

zoechi commented on Dec 19, 2018

tvolkert commented on Dec 19, 2018

jonahwilliams commented on Jan 25, 2019

jonahwilliams commented on Jan 28, 2019

jonahwilliams commented on Feb 5, 2019

jonahwilliams commented on Apr 21, 2019

vishna commented on Sep 26, 2019

DanTup commented on Feb 20, 2020

aloisdeniel commented on Feb 20, 2020

jonahwilliams commented on Feb 20, 2020

28 remaining items

flutter-triage-bot commented on Nov 3, 2025

flutter-triage-bot commented on Nov 18, 2025

flutter-triage-bot commented on Jan 23, 2026

flutter-triage-bot commented on Jun 1, 2026

bkonyi commented on Jun 1, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions