AutoConfiguration constructor

Declares a class as a source of automatic configuration.

This annotation marks a class that provides pods, services, or other application components that should be automatically discovered and registered by the framework during application startup.

🚀 How it Works:

• The framework automatically scans all classes annotated with @AutoConfiguration during bootstrap.
• Any methods within these classes annotated with @Pod are treated as factory methods and their return values are registered as pods in the application context.
• Typically, this is used for library-level default configurations or framework-provided setups.

🎯 Target Use Cases:

• Automatically register commonly used pods (e.g., Logger, HttpClient)
• Provide cross-cutting concerns (e.g., metrics, tracing)
• Reduce boilerplate in app-level configuration

🔧 Requirements:

• The annotated class must have a public zero-argument constructor (if not using static methods).
• @Pod methods must return non-null values that will be added to the DI container.

🧪 Example:

@AutoConfiguration()
class DefaultInfrastructure {
  @Pod()
  Logger logger() => Logger();

  @Pod()
  HttpClient client() => HttpClient();
}

⚠️ Notes:

• If you don’t want a class to be automatically discovered, use @Configuration() instead and import it manually.
• Avoid putting app-specific configuration in an @AutoConfiguration class — it's meant for shared, reusable modules.

🗂 Organization Tip:

Use this in reusable package-level configurations, such as:

• logging_config.dart
• database_auto_config.dart
• http_auto_config.dart

🔧 Related:

• @Pod() → Marks methods that return injectable components.
• @Configuration() → Similar, but not auto-scanned; must be imported.

Applies to:

• class declarations only.