1. Problème initial : appel de service sans effet visible

Lors du clic sur un bouton « Scanner » dans l’application principale, aucune navigation vers l’interface de scan ne se produisait, et le journal affichait undefined lors de l’appel à ServiceManager.getService<IScanRouter>('IScanRouter').

Text('Scanner').fontColor('#ffffff')
  .onClick(() => {
    const router = ServiceManager.getService<IScanRouter>('IScanRouter');
    console.info('Service obtenu :', router); // → undefined
    router?.navigateToScan();
  });

La cause était simple mais facile à négliger : le service personnalisé IScanRouter n’était pas enregistré dans le contexte de l’application principale. Contrairement aux services natifs du système, les srevices définis par l’utilisateur doivent être explicitement déclarés via ServiceManager.registerService().

Solution appliquée : appel de la fonction d’initialisation setupSharedServices() au démarrage de EntryAbility :

// entry/src/main/ets/ability/EntryAbility.ts
import { setupSharedServices } from '@internal/core-services';

export class EntryAbility extends UIAbility {
  onCreate(want: Want, launchParam: AbilityConstant.LaunchParam): void {
    super.onCreate(want, launchParam);
    setupSharedServices(this.context); // Enregistre IScanRouter et autres
  }
}

Dans le module @internal/core-services, l’implémentation suit ce schéma :

export function setupSharedServices(context: Context): void {
  ServiceManager.registerService<IScanRouter>(
    'IScanRouter',
    ScanRouterImpl.getInstance(context)
  );
}

2. Plantage après enregistrement : erreur de résolution de module

Une fois le service enregistré, l’application échouait immédiatement au lancement avec l’erreur suivante :

Cannot resolve module '&@bdmap/verify/Entry&1.0.4'. Check bundle path and dependencies.

L’analyse a révélé que l’implémentation ScanRouterImpl utilisait en interne le package @bdmap/verify, absent du projet cible. L’ajout direct de cette dépendance dans oh-package.json5 n’a pas suffi :

"dependencies": {
  "@bdmap/verify": "1.0.4"
}

3. Dépendances transitoires manquantes : résolution par version contrôlée

Même après installation de @bdmap/verify@1.0.4, l’erreur persistait. Une inspection approfondie de son package.json a montré qu’il dépendait fortement de quatre modules internes :

• @bdmap/base@^1.2.1
• @bdmap/map@^1.2.8
• @bdmap/search@^1.2.8
• @bdmap/locsdk@1.1.5

Or, HarmonyOS ne valide pas les versions transitoires lors de la compilation — l’erreur n’apparaît qu’au moment du chargement dynamique du module à l’exécution.

Pour garantir la cohérence, la section overrides a été ajoutée à oh-package.json5 :

"overrides": {
  "@bdmap/base": "^1.2.1",
  "@bdmap/map": "^1.2.8",
  "@bdmap/search": "^1.2.8",
  "@bdmap/locsdk": "1.1.5"
}

Cette configuration force l’usage exact de ces versions pour tous les pakcages @bdmap/*, évitant ainsi les conflits de compatibilité lors du lien dynamique.

4. Bonnes pratiques tirées de l’expérience

• Enregistrement explicite : tout service personnalisé doit être déclaré avant toute utilisation — aucun mécanisme d’auto-découverte n’est fourni.
• Gestion stricte des versions : les packages HAR privés avec dépendances couplées nécessitent une synchronisation rigoureuse ; overrides est indispensable dans les projets multi-modules.
• Diagnostic hiérarchique : face à Cannot resolve module, prioriser l’audit des dépendances (présence → version → export correct dans module.json5).