mirror of
https://github.com/meshtastic/Meshtastic-Android.git
synced 2026-09-18 17:19:42 -04:00
James RichandClaude Sonnet 5
58d1d5068c
core:data ties together core:database, core:datastore, core:di, core:model, core:network, core:prefs, core:repository (all already wasmJs-enabled), core:takserver (out of scope, relocated below), and Room -- the last of which turned out to be the real blocker. core:takserver's dependency moves to nonWebMain-only: a grep pass confirmed core:data's own commonMain never actually references org.meshtastic.tak (the only "TAK" substring matches were the unrelated PortNum.ATAK_PLUGIN protobuf constant and a code comment), so this is a mechanical relocation, not a port -- core:takserver itself stays out of scope (niche ATAK feature). MqttManagerImpl.kt duplicated the exact TCP+WS transport composition core:network's MqttTransportSelection.kt already solved for MQTTRepositoryImpl. Rather than duplicate the platform-selection logic (and its TCP-exclusion reasoning) a second time, core:network's mqttTransportFactory drops its `internal` modifier and becomes public; MqttManagerImpl.kt's one-off probe client now calls it directly. The real, unpredicted blocker: core:database exposes Room only as `implementation` in its own commonMain, so RoomDatabase -- the supertype of MeshtasticDatabase that core:data's repositories reach through DatabaseProvider -- isn't visible to external consumers on wasmJs. This never surfaced on android/jvm/iOS because core:data's own jvmAndroidMain already carries the identical redundant Room redeclaration, for the same reason, pre-dating this session. Fixed with a matching wasmJsMain dependency on androidx.room.runtime/androidx.room.paging (both confirmed to publish real wasmJs variants; sqlite-bundled stays excluded, native-only and unrelated to RoomDatabase itself). core:database's own implementation-vs-api Room exposure would be a cleaner long-term fix but is out of this pass's scope since nothing else currently needs it. 14 of core:data's 33 commonTest files -- the ones that actually import core:testing (core:testing itself has no wasmJs target, same gap core:ble/core:database/core:network hit) -- move to a new nonWebTest source set; confirmed empirically that core:data's own compileTestKotlinWasmJs task genuinely needs every commonTest dependency to resolve, even with no browser()/nodejs() test executor configured -- this is a real compile-time constraint on every module, not something a bare wasmJs() sidesteps by omission. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>