Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

SafeAreaView is re-exported unwrapped from the safe-area-context shim: className silently no-ops (breaks flex-1 screen roots after v4 -> v5 migration)

Ouverte
  • Quelque chose ne va pas ?
#386 1 commentaire 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 3 jours

@nimbly1 y travaille déjà.

Depuis le 4/10/2026.

  • #468 par @nimbly1 — ouverte

Évaluation

Difficulté
2/5
Temps estimé
1-3 heures
Accessibilité débutants
28/100
Type d'issue
Bug
Clarté
Clairement spécifiée
Activité
À l'abandon
Stack technique
react-native, typescript
Domaine
frontend, mobile

Piste de recherche

The bug is in the shim at src/components/react-native-safe-area-context.native.tsx, which re-exports SafeAreaView unwrapped, so className is dropped. Read how the other intercepted components are wrapped in that file, then check whether linked PR #468 already covers this before starting. Done means className on SafeAreaView maps to style, with a test or on-device check showing a flex-1 root fills the screen.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

auto-triaged bug confirmed

Summary

The react-native-safe-area-context shim wraps SafeAreaProvider (to expose the inset CSS variables) but re-exports everything else from the original package unwrapped:

// src/components/react-native-safe-area-context.native.tsx
export * from "react-native-safe-area-context";

export function SafeAreaProvider({ children, ...props }: SafeAreaProviderProps) { ... }

SafeAreaView is therefore the original component, and className on it is a silent no-op — no warning, no error.

Why this is painful

<SafeAreaView className="flex-1 ..."> is an extremely common screen-root pattern in NativeWind v4 apps (the v4 JSX transform made it work on any component). After migrating to NativeWind v5 / react-native-css, every such screen root silently loses flex: 1, the SafeAreaView collapses to content height, and ScrollViews inside shrink to zero — the entire screen body renders blank while headers/tab bars (styled via style objects) keep working.

Nothing catches it statically: tsc, jest, and expo export are all green (the CSS compiles fine; it just never reaches the component). We only found it via on-simulator UAT. In our app it affected 44 SafeAreaView className call sites, i.e. every screen.

Environment

  • react-native-css 3.0.7, nativewind 5.0.0-preview.4, tailwindcss 4.3.3
  • Expo SDK 57, React Native 0.86, New Architecture enabled, pnpm monorepo (hoisted)
  • Metro via withNativewind(config, { inlineVariables: false }), default globalClassNamePolyfill (true)

Repro

import { SafeAreaView } from "react-native-safe-area-context";

export default function Screen() {
  return (
    <SafeAreaView className="flex-1 bg-red-500">
      <Text>never gets a red full-height background</Text>
    </SafeAreaView>
  );
}

<View className="flex-1 bg-red-500"> in the same tree styles correctly, confirming the CSS pipeline itself works.

Suggested fix

Wrap SafeAreaView in the shim like the other intercepted components, e.g.:

import { SafeAreaView as OriginalSafeAreaView } from "react-native-safe-area-context";
import { useCssElement } from "react-native-css";

export function SafeAreaView(props: SafeAreaViewProps & { className?: string }) {
  return useCssElement(OriginalSafeAreaView, props, { className: "style" });
}

We are currently shipping exactly that as a local pnpm patch on dist/ (module + commonjs) and it fully restores v4 behavior — all screens render identically to our NativeWind 4 baseline.

More generally: a dev-mode warning when className is passed to a component that nothing intercepts would have turned a multi-hour debugging session into a one-line console message. Happy to open a PR for the SafeAreaView wrap if useful.

Langage dominant
TypeScript
Étoiles
166
Forks
45
Merge moyen
13 j 14 h
PR mergées (30 j)
1

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de nativewind/react-native-css

Toutes les issues de nativewind/react-native-css

Issues similaires

Plus d'issues TypeScript

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.