@jacques_gordon/expo-mapbox-navigation 2.2.16 → 2.2.18

package/ios/_MapboxNavigationNativeImportShim.swift

@@ -0,0 +1,22 @@
+// MapboxNavigationCore depends internally on MapboxNavigationNative (native
+// ObjC classes such as MBNNAmenity), but no file in this module calls its
+// APIs directly. React Native/Expo's CocoaPods post_install SPM step
+// re-derives which package products a pod target actually needs
+// (independently of our own config-plugin hook that explicitly registers it
+// via Xcodeproj manipulation), and that derivation appears to work off of
+// literal `import` statements found in Swift source files. Without an
+// explicit import somewhere in this module, that step silently drops the
+// MapboxNavigationNative product dependency after our hook adds it, causing
+// "Undefined symbols" for MBNN* classes at the final app link step — even
+// though the package resolves correctly and MapboxNavigationCore itself
+// compiles fine.
+//
+// This import is isolated in its own file (rather than placed in
+// ExpoMapboxNavigationView.swift) because MapboxNavigationNative exposes raw
+// types that collide by name with types MapboxNavigationCore re-exports at a
+// higher level (e.g. Waypoint, and enum cases like .automobile, .walking,
+// .cycling, .automobileAvoidingTraffic). Importing both modules in the same
+// file makes those symbols ambiguous to the compiler. Keeping this import in
+// its own compilation unit, with nothing else in the file, satisfies the
+// SPM auto-detection step without affecting name resolution anywhere else.
+import MapboxNavigationNative

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@jacques_gordon/expo-mapbox-navigation",
-  "version": "2.2.16",
+  "version": "2.2.18",
   "description": "Expo module for Mapbox Navigation SDK with 16KB page size support, NDK27, and Mapbox Maps v11.11.0+",
   "main": "build/index.js",
   "types": "build/index.d.ts",