[flutter_hook_config] Add the flutter_hook_config package

[bdero]

Towards flutter/flutter#186299

This came out of an exchange with @dcharkes here: flutter/flutter#186300 (comment)

Adds flutter_hook_config, a package:hooks protocol extension owned by Flutter.

The intent: flutter_tools constructs a FlutterExtension and passes it to every build and link hook invocation, populating it with engine host-tool paths resolved through Artifacts.getHostArtifact (so the --local-engine override applies, same as for flutter_tools' own build steps). Build hooks then read those paths through a typed accessor instead of re-deriving them by walking the SDK cache directory, which is what packages like flutter_gpu_shaders do today (and which misses --local-engine).

What a Flutter build hook looks like with it:

import 'package:flutter_hook_config/flutter_hook_config.dart';
import 'package:hooks/hooks.dart';

void main(List<String> args) async {
  await build(args, (input, output) async {
    if (input.config.buildForFlutter) {
      final impellerc = input.config.flutter.impellerc; // absolute Uri
      // ... invoke impellerc to compile a shader bundle ...
    } else {
      // Plain `dart` build, or a Flutter SDK without this extension:
      // fall back to the hook's own tool discovery.
    }
  });
}

v1 exposes impellerc and libtessellator; more host artifacts can be added later as null-checked fields. Pure Dart, depends on hooks: ^1.0.0, starts at 0.1.0 while the shape stabilizes. The flutter_tools side lands in a separate flutter/flutter PR and depends on this being published first.

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.

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. ↩ ↩²

[bdero]

Note: label needs to be created

[bdero]

Note for shipping this: flutter_hook_config is a brand-new package, so on its first publish the release workflow will publish it under the bot publisher account rather than the flutter.dev verified publisher. Someone on the Flutter team with publisher-account access will need to do the one-time transfer from the package's Admin tab on pub.dev afterward (per the packages release process docs; access is tracked internally at b/191674407). Happy to coordinate in #hackers-ecosystem.

Also flagging: the top-level README.md row and the issue_tracker URL reference pub.dev/packages/flutter_hook_config and the flutter/flutter label p: flutter_hook_config, neither of which exists yet, so the badges/links will 404 until the package publishes and the label is created.

[bdero]

Added this following the template of other new packages. I assume this is correct but not 100% sure. I'm CLA signed of course, but I no longer work at Google.

[gemini-code-assist]

Code Review

This pull request introduces the flutter_hook_config package, a package:hooks protocol extension that allows the Flutter SDK to provide engine host-tool paths like impellerc and libtessellator to build and link hooks. The PR includes the package's core configuration logic, a ProtocolExtension implementation, documentation, and unit tests. A review comment suggests improving the assertions in the setupFlutter method to explicitly verify that provided URIs use the 'file' scheme, ensuring more descriptive error messages for developers.

[dcharkes]

Are these two related? Do they change together? If yes they should maybe be nested in an object together.

Also, does every Flutter have impeller? E.g. With third-party forks of Flutter is there ever a possibility there's no impeller? If yes, then that wrapper object should be nullable. And if it's not null both fields are non-nullably provided.

Do we need a some kind of version number for this? e.g. if any of these files change or the underlying formats change, you'd want the hook to be rerun.

[bdero]

Also, does every Flutter have impeller? With third-party forks of Flutter is there ever a possibility there's no impeller? If yes, then that wrapper object should be nullable. And if it's not null both fields are non-nullably provided.

impellerc is used for both Impeller and Skia. Even if one were to do the heavy work of ripping out Impeller from the engine (since we don't even ship Skia on iOS), features like the Fragment Program API/RuntimeEffect use impellerc to compile shaders regardless of the graphics backend (impellerc transpiles to SkSL for Skia).

The impellerc dependency is baked elsewhere in flutter_tools already.

[bdero]

Do we need a some kind of version number for this? e.g. if any of these files change or the underlying formats change, you'd want the hook to be rerun.

Hmm yes that's a good point and we should think about this... Since the artifacts are per-engine build, maybe the right thing to do would be to add a config.flutter.engineVersion, so that the cache key gets invalidated whenever the engine artifacts change. I can just grab the engine revision from Cache.engineRevision in flutter_tools.

Does that seem right?

[bdero]

Added engineVersion.

[dcharkes]

Side note: I'm publishing a 2.0.0 soon, because we need to add a method to the ProtocolExtension (dart-lang/native#3358).