feat: add GetIt::findFirstFactory method and Expose ServiceFactory,ServiceFactoryType

[Hu-Wentao]

This change allows developers to programmatically query the state of a service's underlying ServiceFactory within the container. This is achieved by making the ServiceFactory class and ServiceFactoryType enum public, and by adding a new findFirstFactory method. This enables the creation of more powerful and dynamic tools and frameworks on top of the GetIt platform.

Motivation for Framework and Tool Developers

When building a framework or developer tool on top of GetIt, it's often necessary to understand how a service was registered, not just that it exists. This new API provides that capability, which is valuable for:

• Lifecycle-aware Logic: A framework can now verify that a service intended for caching is correctly registered as a singleton and provide warnings to the user if it's misconfigured.

• Dependency Analysis Tools: A developer tool could scan the container, visualize the dependency graph, and label each node with its registration type (singleton, lazySingleton, factory), providing a clear architectural overview.

• Automatic Validation: A testing framework could automatically assert that services with a specific annotation are registered with an expected lifecycle, reducing boilerplate and enforcing conventions.

Key Changes

• Exposed ServiceFactory and ServiceFactoryType:

The ServiceFactory abstract class and the ServiceFactoryType enum are now public APIs, allowing them to be used in external code.

• New GetIt.findFirstFactory Method:

A new method, ServiceFactory? findFirstFactory({String? instanceName}), has been added to the GetIt interface.

It returns the ServiceFactory instance for a given type, allowing access to its .type property and other potential factory state.

Usage Example

// 1. Register a service as a lazy singleton
getIt.registerLazySingleton<ApiService>(() => ApiServiceImpl());

// 2. A framework or tool can now query the factory's state
final factory = getIt.findFirstFactory<ApiService>();

// 3. Execute logic based on the queried state
if (factory != null) {
  print('ApiService factory type: ${factory.type}');
  // -> Expected output: ApiService factory type: ServiceFactoryType.lazySingleton
  
  // Assert that its lifecycle meets framework requirements
  assert(factory.type == ServiceFactoryType.lazySingleton);
} else {
  print('ApiService is not registered.');
}

[escamoteur]

Only the thing about the redefining of the registration type.
Otherwise I can see how this would be an advantage for tool authors and only exposing an part of the ServiveFactory and not the full class is a good option.
I would be happy to see you on our discussion here https://github.com/orgs/flutter-it/discussions

[escamoteur]

wouldn't it be better to make the enum itself public then instead of redefining it?

[Hu-Wentao]

Of course, but I'm using version 8.0.0-pre-1, and redefining the enum might cause more conflicts when updating older versions.

[escamoteur]

why is your format so different? It makes it a bit difficult to diff?

[Hu-Wentao]

It is indeed a mistake. Although I found it before submitting, IDEA may have automatically reformatted the code after submitting.

[escamoteur]

How could it make problems if the enum was not exposed before? Am 29. Juli 2025, 20:43 -0500 schrieb Hu Wyatt ***@***.***>:

…

@Hu-Wentao commented on this pull request. In lib/get_it.dart: > @@ -11,6 +11,16 @@ import 'package:meta/meta.dart'; part 'get_it_impl.dart'; +/// You will see a rather esoteric looking test `(const Object() is! T)` at several places. +/// It tests if [T] is a real type and not Object or dynamic. + +/// For each registered factory/singleton a [_ServiceFactory<T>] is created +/// it holds either the instance of a Singleton or/and the creation functions +/// for creating an instance when [get] is called +/// +/// There are three different types: +typedef ServiceFactoryType = _ServiceFactoryType; Of course, but I'm using version 8.0.0-pre-1, and redefining the enum might cause more conflicts when updating older versions. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: ***@***.***>

[Hu-Wentao]

I'd actually noticed the formatting issue early on and tried to reduce the discrepancies by typedefing ServiceFactoryType.

However, today, using Flutter 3.32.8 (Dart 3.8.1), I reformatted the code using the dart format command, and the indentation discrepancies persisted.

In the end, I manually fixed the discrepancies (the differences weren't as significant as I'd expected).

[escamoteur]

thanks alot for overhauling the PR.

I was just wondering, if it would make sense to rename findFirstFactory to findFirstRegistration? As it's not only Factories?

What doe you think?

[escamoteur]

I will merge it but rename ServiceFactory to ObjectRegistration because it makes more sense IMHO

[escamoteur]

please see #416 includes in V8.2.0