[MOO-2225] migrate geolocation to react native nitro geolocation

[stelselim]

Migrate react native nitro geolocation

[vadymv-mendix]

Good news — I think we may be able to drop the hand-rolled web branch entirely here. The library ships web support for the Modern API root import: browser builds resolve to src/index.web.tsx, which is backed by navigator.geolocation and doesn't load any Nitro native bindings. Its getCurrentPosition has the same signature and also returns a promise, so await getCurrentPosition(options) should work unchanged on both platforms and the whole isReactNative/isWeb split could go away. Same applies to watchPosition/unwatch in GetCurrentLocationMinimumAccuracy.ts — the web entry exports those with identical signatures (string tokens included).

One thing worth verifying before we rely on it: whether the Mendix web client resolves the package's browser/exports condition. If it does, this simplifies both actions a lot. If it doesn't, then the manual branch is the right call and we should keep it with a short comment saying why, so the reason is obvious next time someone reads it.

[vadymv-mendix]

This import should probably happen inside the native branch instead, via require("react-native") — that's the pattern the other cross-platform actions here use (OpenURL, Share, CallPhoneNumber). Top-level ESM imports are eager, so on web this still resolves even though only the iOS timeout clamp actually needs it.

Platform is used in just the one place (the Platform.OS === "ios" check in buildLocationOptions), so making it lazy is cheap:

if (isReactNative && require("react-native").Platform.OS === "ios") { ... }

Same applies to GetCurrentLocationMinimumAccuracy.ts:9.

[vadymv-mendix]

Small correctness issue here: new Big(0) is truthy, so a configured timeout of 0 gives timeoutMs = 0, and setTimeout then fires onTimeout on the next tick — rejecting with "Timeout expired" before any position can arrive.

It's also worth noting that buildLocationOptions below maps 0 to 3600000 ("no timeout"), so with timeout = 0 the location layer is told one hour while this watchdog fires immediately — the two timeout computations end up disagreeing. Could we derive both from a single clamped value? Something like:

const timeoutMs = options.timeout ?? 30000;

One related thing: the 0 -> 3600000 clamp is currently inside the Platform.OS === "ios" check, so 0 still reaches Android and navigator.geolocation unclamped, and on web timeout: 0 means "fail immediately with TIMEOUT" on every update. Might be worth lifting that clamp out of the iOS-only branch.

The : 30000 fallback itself is a nice improvement over what was there before, where an empty timeout gave Number(undefined) -> NaN.

[vadymv-mendix]

Minor: the ?? undefined is redundant here — options.timeout and options.maximumAge are already typed number | undefined, so this is a no-op and can just be options.timeout / options.maximumAge.

Same two lines exist in GetCurrentLocationMinimumAccuracy.ts:71-72.

[vadymv-mendix]

This narrowing can be simplified — the right-hand side already handles the Error case, since error.message works either way. So this is equivalent:

const message = error?.message ?? String(error);

[vadymv-mendix]

normalizeWebPosition is duplicated verbatim in both geolocation actions, and the library already exports an equivalent (normalizePosition in its web entry, which also sets provider).

If we end up using the library's built-in web support, this can be removed outright. If we keep the manual path, could we add a short note that the two copies need to stay in sync? Sharing across two action files isn't really possible in the Mendix model as far as I know, so a comment is probably the most we can do.

[vadymv-mendix]

This quote change (the apostrophe in "you're") is outside the BEGIN USER CODE block, so Studio Pro will regenerate over it on the next deploy. Probably worth reverting just to keep the diff focused on the migration.

[vadymv-mendix]

invariant looks like it can go now — it was only here for @react-native-community/geolocation. The comment in configs/jsactions/rollup.config.mjs (the nanoflowcommons branch) says as much, and it links to the exact line in that library that used it silently.

I checked the remaining nanoflowcommons dependencies (async-storage, js-base64, permissions, geocoder, nitro-geolocation, nitro-modules) and none of them reference invariant, so both this entry and the copy step in rollup.config.mjs could be removed. That would be a nice bit of cleanup to land with the migration, since this PR is what makes it dead.

[vadymv-mendix]

Could you double-check this version bump? CHANGELOG.md already has a ## [7.2.0] Nanoflow Commons - 2026-7-3 section, and it describes the OpenURL offline-db change rather than this migration — so this would be a second, different 7.2.0.

I had a look at the release scripts to make sure this wasn't handled automatically: BumpVersion.ts only scans packages/pluggableWidgets, so it doesn't touch this package, and marketplaceRelease.js reads the version straight out of package.json to publish under. So it looks like whatever is here is what ships. 7.3.0 plus a fresh changelog section for the migration is probably what we want — happy to be corrected if the release flow works differently than I'm reading it.

[vadymv-mendix]

Worth documenting why this is needed, since it's non-obvious. react-native-nitro-geolocation ships no compiled JS at all — the tarball has 0 .js files and 54 .ts/.tsx, with main: "src/index" and browser: "src/index.web.tsx" — so the TS plugin needs jsx set in order to parse the .tsx entry point. I confirmed it's load-bearing: without it the build fails with TS6142: Module ... was resolved to '.../src/index.tsx', but '--jsx' is not set.

The flag itself is fine. The thing I'd want confirmed before merge is the consequence: the client now resolves raw TSX at runtime for this dependency, where the old library shipped lib/commonjs + lib/module. That's worth a quick sanity check in a real app (web especially), independent of the web-support question on GetCurrentLocation.ts.

Could you add a short comment here noting why jsx is required? Otherwise it looks unrelated to a geolocation migration and someone may remove it later.

[vadymv-mendix]

Nice cleanup overall — dropping the RNFusedLocation/RNCGeolocation NativeModules probing and the hand-written typings/Geolocation.d.ts shim removes real complexity, and that shim only existed to paper over the two competing implementations in the old library. Adding clearTimeout/clearWatch to onError in the minimum-accuracy action also fixes a leak that was there before, which is a good catch.

I've left a few inline comments — the only one I'd call blocking is the timeout = 0 handling in GetCurrentLocationMinimumAccuracy.ts, since new Big(0) is truthy and the watchdog ends up firing immediately.

Two things that would be good to add to the PR:

• A CHANGELOG.md entry under [Unreleased].
• Removal of the now-unused invariant dependency and its copy step in configs/jsactions/rollup.config.mjs (details in the inline comment).

And one non-blocking design question, mostly for your judgement since you know the intended UX better than I do: onError now rejects even when lastAccruedPosition already holds a usable fix. For an action whose whole purpose is "best effort within a timeout," falling back to the best-so-far on a transient POSITION_UNAVAILABLE might serve users better than failing outright. This behaves the same as before the PR so it's not a regression — just seemed worth a deliberate decision rather than inheriting it.

Last thing, and the main risk I see: the new library ships no compiled JavaScript, so the client resolves raw .tsx at runtime (hence the new jsx flag in the rollup config). Combined with the web-support question on GetCurrentLocation.ts:10, I'd want this properly tested in a real app on both native and web before merging — that's the one thing I couldn't verify from the repo alone.