rnmapbox/maps

[Bug]: showPointOfInterestLabels and other v11 style config values are rejected by types

Open

#3,893 opened on Jun 30, 2025

 (0 comments) (1 reaction) (0 assignees)Kotlin (941 forks)auto 404
bug 🪲good first issuetypescript

Repository metrics

Stars
 (2,884 stars)
PR merge metrics
 (PR metrics pending)

Description

Mapbox Implementation

Mapbox GL

Mapbox Version

11.8.0

React Native Version

0.79.3

Platform

iOS

@rnmapbox/maps version

10.1.39

Standalone component to reproduce

import React from 'react';
import {
  MapView,
  StyleImport
} from '@rnmapbox/maps';

class BugReportExample extends React.Component {
  render() {
    return (
      <MapView style={{flex: 1}} styleURL={'mapbox://styles/mapbox/standard'}>
      <StyleImport
        id="basemap"
        existing
        config={{
          lightPreset: "day",
          // ^^ this one is fine
          showPointOfInterestLabels: false,
          // ^^ this one gets rejected by TS, even though providing the value yields the expected results
        }}
      />
      </MapView>
    );
  }
}

Observed behavior and steps to reproduce

When trying to provide boolean values (such as showPointOfInterestLabels) to the StyleImport's config object, TypeScript rejects them, as the expected type is [key: string]: string;. However, certain config objects are booleans, and providing them as strings (like "false") doesn't work.

Note that despite TS telling otherwise, applying the config property does have an effect:

Expected behavior

The StyleImport object should also accept booleans as values (or probably all the possible key/value types should be typed), as per Mapbox's documentation. iOS: https://docs.mapbox.com/ios/maps/guides/migrate-to-v11/ Android: https://docs.mapbox.com/android/maps/guides/migrate-to-v11/#explore-new-features

Notes / preliminary analysis

I'm happy to open a PR with changing the types, but I'm not sure if just replacing [key: string]: string; with showPlaceLabels: boolean; lightPreset: string; etc... is going to work, as probably non-Standard styles need the current types backward compatibility?

Additional links and references

No response

Contributor guide