GetX + Dio + EasyLocalization + HugeIcons: Naming Conflicts, Strict Inference, and Import Path Bugs

[codebyforam]

Configuration Used

• Architecture: Clean Architecture & Feature-first structure
• • State Management: GetX, GetX Routing, GetX Bindings
• • • Networking: Dio
• • • • Icons: HugeIcons
• • • • • Localization: easy_localization (default-bundled)

---

Description of Issues Found

1. Ambiguous Exports and Naming Conflicts

When packages_imports.dart exports package:get/get.dart (or when sub-packages are exported alongside dio and easy_localization), name collisions occur:

• BuildContext Extension Collision (theme property): Both GetX's navigation extension (ContextExtensionss) and the custom generated ContextExtension in lib/src/extensions/context_extension.dart define theme.
• • String Extension Collision (tr method): Both GetX's translation extension (Trans) and easy_localization's extension (StringTranslateExtension) define the tr() method.
• • • Class Collisions: FormData, MultipartFile, and Response are defined in both package:dio/dio.dart and package:get/get.dart (via its HTTP module).
      Fix: Update the GetX export statement in lib/src/imports/packages_imports.dart to:

export 'package:get/get.dart' hide ContextExtensionss, Trans, StringExtension, FormData, MultipartFile, Response;

2. Invalid Import Paths for AuthController

The generated screens and binding files attempt to import AuthController from controllers/auth_controller.dart, but the file is generated in the providers directory:

• Correct path: package:atmadarshan/src/features/auth/presentation/providers/auth_controller.dart
• • Generated import: package:atmadarshan/src/features/auth/presentation/controllers/auth_controller.dart
    This causes compilation failures in:
• lib/src/features/auth/presentation/screens/signup_screen.dart
• • lib/src/features/auth/presentation/screens/login_screen.dart
• • • lib/src/features/auth/presentation/screens/forgot_password_screen.dart
• • • • lib/src/routing/app_bindings.dart
        Fix: Change the generated imports to point to providers/.

3. Strict Type Inference Warnings

With strict analysis options enabled, calling GetX navigation methods without specifying explicit type parameters raises warnings because the return types cannot be inferred.

Fix: Add explicit <dynamic> type arguments:

Get.toNamed<dynamic>(AppRoutes.forgotPassword);
Get.offAllNamed<dynamic>(AppRoutes.home);

And GetPage<dynamic> type arguments for AppRouter.getPages.

4. HugeIcons Rendering and Type Mismatch

• AppIcon in lib/src/shared/widgets/app_icon.dart is typed as accepting IconData, but layouts pass HugeIcons.strokeRoundedHome01 which has a type of List<List<dynamic>>.
• • The generator outputs HugeIcons.strokeRoundedTickCircle in show_toast.dart, which does not exist in hugeicons: ^1.1.5 (the correct name is HugeIcons.strokeRoundedCheckmarkCircle01).
    Fix: Update AppIcon to accept dynamic and dynamically render either standard Icon or HugeIcon.

5. Missing Configuration Assets in pubspec.yaml

pubspec.yaml registers .env and assets/images/ as assets, but they are not created by default.

Fix: The generator should output an empty .env file and create the assets/images/ directory with a .gitkeep placeholder.

[codebyforam]

Issue Report: Build & Analyzer Failures with GetX + Clean Architecture + HugeIcons Configuration

Generation Options Used

• Architecture: Clean Architecture (Feature-first structure)
• • State Management & Routing: GetX, GetX Routing, GetX Bindings
• • • Networking: Dio
• • • • Local Storage: Shared Preferences, Secure Storage
• • • • • Icons: Default Flutter Icons, HugeIcons
• • • • • • UI Utilities: ScreenUtil, Skeletonizer
• • • • • • • Theme: Material 3 (Dark Mode enabled, Primary Color: #C98942)
• • • • • • • • Package Name: com.ashram.mobile
• • • • • • • • • Firebase: Auth, Firestore, Storage, Messaging, Analytics, Crashlytics
• • • • • • • • • • Media & Utilities: Flutter SVG, Image Picker, File Picker, URL Launcher, Permission Handler, Share Plus, Path Provider, Device Info

---

1. Systemic Import & Namespace Conflicts (GetX + easy_localization)

The Issue:

When selecting both GetX and easy_localization (Localization), a namespace conflict occurs because both packages extend String with a .tr() translation method/extension:

• easy_localization defines extension StringTranslateExtension on String (.tr())
• • GetX defines extension Trans on String (.tr())
    Additionally, packages_imports.dart selectively exported sub-components of GetX instead of the main entry point, causing Get.find and Get.toNamed to fail compilation across screens.

The Fix:

Export package:get/get.dart inside packages_imports.dart.hbs but selectively hide clashing extensions and classes:

{{#if (or flags.isGetX (eq flags.routerPackage "getx"))}}
export 'package:get/get.dart' hide ContextExtensionss, Trans, StringExtension, FormData, MultipartFile, Response;
{{/if}}

---

2. Controller Path Mismatch in Clean Architecture

The Issue:

Under the Clean Architecture (Feature-first) layout, AuthController is outputted to the providers/ directory (features/auth/presentation/providers/auth_controller.dart). However, templates like app_bindings.dart.hbs, login_screen.hbs, signup_screen.hbs, and forgot_password_screen.hbs attempted to import it from controllers/, resulting in missing import compile errors.

The Fix:

Corrected the Handlebars condition across bindings and screens to point to providers/:

{{#if (eq architecture "layer-first")}}
import 'package:{{flags.appSnake}}/src/presentation/providers/auth/auth_controller.dart';
{{else if (eq architecture "mvc")}}
import 'package:{{flags.appSnake}}/src/controllers/auth/auth_controller.dart';
{{else if (eq architecture "mvvm")}}
import 'package:{{flags.appSnake}}/src/ui/auth/controllers/auth_controller.dart';
{{else}}
import 'package:{{flags.appSnake}}/src/features/auth/presentation/providers/auth_controller.dart';
{{/if}}

---

3. Strict Type Inference Warnings (strict-inference / strict-raw-types)

The Issue:

The generated project's analysis_options.yaml enables strict Dart typing:

analyzer:
  strong-mode:
    strict-inference: true
    strict-raw-types: true

Because of this:

1. Calling raw navigation helpers (Get.toNamed(...) or Get.offAllNamed(...)) fails analyzer checks because the compiler cannot implicitly infer their generic type argument <T>.
2. 2. Declaring raw List<GetPage> fails because GetPage is a generic class (GetPage<T>) and cannot be declared raw.

The Fixes:

• Appended <dynamic> type parameters to navigation calls:
• Get.toNamed<dynamic>(AppRoutes.login);
• Get.offAllNamed<dynamic>(AppRoutes.home);
• • Explicitly typed the router list and page elements:
• • static List<GetPage<dynamic>> get getPages => [ GetPage<dynamic>(...) ];

---

4. Widget Compatibility with HugeIcons Vector Data

The Issue:

The generated AppIcon widget strictly expected IconData as its icon parameter. However, selecting HugeIcons passes a custom path-drawing list (List<List<dynamic>>) to the widget instead of IconData, crashing the compiler.

The Fix:

Refactored app_icon.dart.hbs to accept a dynamic icon, and added type checks inside the build method to safely render either standard icons or HugeIcon vector paths:

  final dynamic icon;

  @override
  Widget build(BuildContext context) {
    if (icon is IconData) {
      return Icon(icon as IconData, size: size, color: color);
    }
    {{#if flags.usesHugeicons}}
    if (icon is List<List<dynamic>>) {
      return HugeIcon(
        icon: icon as List<List<dynamic>>,
        color: color ?? Theme.of(context).iconTheme.color ?? Colors.black,
        size: size ?? 24.0,
      );
    }
    {{/if}}
    return const SizedBox.shrink();
  }

---

5. Deprecated/Incorrect HugeIcons Constant

The Issue:

The default success toast icon inside show_toast.dart.hbs referenced HugeIcons.strokeRoundedTickCircle, which does not exist in the latest versions of the package.

The Fix:

Changed the icon constant to the correct, updated name:
HugeIcons.strokeRoundedCheckmarkCircle01

---

6. Missing Configuration & Image Directories

The Issue:

The generated pubspec.yaml registers .env under assets and configures assets/images/, but the generator fails to produce them, triggering Flutter compilation failures due to missing assets.

The Fix:

Added logic in the generator backend (app/lib/generator/index.ts) to write an empty .env and assets/images/.gitkeep placeholder inside the output zip directory:

await fs.writeFile(path.join(workingDir, ".env"), "");
const imagesDir = path.join(workingDir, "assets", "images");
await fs.mkdir(imagesDir, { recursive: true });
await fs.writeFile(path.join(imagesDir, ".gitkeep"), "");

[Arjun544]

@codebyforam thank you for the feedback.

I actually noticed these errors myself, but I held off on fixing them because I am planning to remove the GetX ecosystem from FlutterInit completely.

Before moving forward, what do you think? Should I remove GetX entirely or should I fix these bugs and proceed with it?

[codebyforam]

@Arjun544 I’ve actually forked the repo and fixed the issues on my end.

Personally, I still think GetX is quite helpful for small-scale projects, beginners, and college students because of its simplicity and fast development workflow.

At the same time, I do understand the long-term architectural concerns around maintaining the GetX ecosystem.

I’d genuinely love to contribute if you already have a roadmap planned for FlutterInit. Otherwise, we can also research and evolve it together into something really valuable for the Flutter community.

Let me know — I’d be happy to help.