Полка React Native и Expo: цена пакета — в клиенте, а не в килобайтах

Полка устроена так же, как вся часть: сначала то, что дают React Native и SDK Expo, и только за стеной — пакет. У каждой строки таблицы ниже есть паспорт: когда пакет не нужен, где в учебнике своя сборка, снимок с датой проверки и условие, при котором строку пора пересмотреть.

У полок для браузера отметка «что умеет платформа» — это Baseline, поддержка во всех основных браузерах. Здесь такого мерила нет: платформа телефона — React Native 0.86 и модули SDK 57, и столбец «Сначала» состоит из них.

В таблицах-снимках ниже столбец «Вес или цена» заполнен ценой, а не килобайтами. JavaScript пакета, конечно, едет в бандле, но раньше веса решает другое: заработает ли пакет в том клиенте, который у вас есть, — об этом следующий раздел. Столбец «Версия» — закрепление SDK 57 на сервере Expo на 14.09.2026, а не последняя версия в npm; последняя записана в цене, если отличается. У пакетов, которых SDK не знает, версия — последняя в npm.

Строка полки стареет не по календарю, а по событию: вышел новый SDK, модуль попал в Expo Go, в npm сменился мажор. Поэтому у каждого паспорта своё «Пересмотреть, если…».

Цена пакета на телефоне складывается из ответов на три вопроса, и у каждого ответа свой источник. Первый: знает ли пакет SDK — есть ли он в списке закреплений, где записано, какую версию ждёт данный SDK. Второй: есть ли у пакета нативная половина — код для iOS и Android в его архиве npm. Третий: вшит ли его модуль в Expo Go.

Третий вопрос решает бинарник, а не npm install. Модуль ищется по имени в реестре — «Модуль — это запись в реестре», — и найдётся, только если его вшили при сборке. Как это выглядит в Expo Go и в своей сборке, разобрано в «Expo Go — чужой бинарник с вашим бандлом»; там же вы запускали отказ AppMetrica.

Сведём три вопроса в одну функцию. Данные в ней записанные: выдержка из bundledNativeModules.json пакета expo 57.0.16, который стоит в проекте автора, выдержка из списка модулей Expo Go для SDK 57 и признак нативной половины по файлам архивов npm. Закрепление в таком списке — точная версия или диапазон с тильдой, тем же знаком, что в диапазонах npm. Пакетов семь: первые четыре стоят в apps/mobile, последние три читатель собирается поставить обычным npm install, то есть последних версий. Строка AppMetrica в выводе — напоминание о том запуске, новое здесь — версии. Прогноз: у каких пакетов функция найдёт расхождение с SDK и в какую сторону?

// выдержка из node_modules/expo/bundledNativeModules.json в проекте автора (expo 57.0.16)
const sdk57: Record<string, string> = {
  "react-native": "0.86.2",
  "react-native-reanimated": "4.5.1",
  "react-native-screens": "~4.26.0",
  "@shopify/flash-list": "2.0.2",
  "react-native-keyboard-controller": "1.21.9",
};

// выдержка из модулей, вшитых в Expo Go для SDK 57 (apps/expo-go/package.json, ветка sdk-57)
const inExpoGo = new Set(["react-native", "react-native-reanimated", "react-native-screens", "react-native-keyboard-controller"]);

// пакеты с нативной половиной: в их архивах npm есть код для iOS и Android
const nativeCode = new Set([...inExpoGo, "react-native-mmkv", "@appmetrica/react-native-analytics"]);

interface Installed {
  name: string;
  version: string;
}

// первые четыре стоят в apps/mobile, последние три читатель хочет поставить из npm
const project: Installed[] = [
  { name: "react-native", version: "0.86.0" },
  { name: "react-native-screens", version: "4.25.2" },
  { name: "@appmetrica/react-native-analytics", version: "4.2.0" },
  { name: "zustand", version: "5.0.15" },
  { name: "react-native-reanimated", version: "4.7.1" },
  { name: "@shopify/flash-list", version: "2.3.2" },
  { name: "react-native-mmkv", version: "4.3.2" },
];

function fits(version: string, pinned: string): boolean {
  if (!pinned.startsWith("~")) return version === pinned;
  const [major, minor, patch] = version.split(".").map(Number);
  const [pMajor, pMinor, pPatch] = pinned.slice(1).split(".").map(Number);
  return major === pMajor && minor === pMinor && patch >= pPatch;
}

function price(pkg: Installed): string {
  const pinned = sdk57[pkg.name];
  const version = !pinned
    ? "SDK о нём не знает"
    : fits(pkg.version, pinned)
      ? "версию держит SDK"
      : `SDK 57 ждёт ${pinned}, стоит ${pkg.version}`;
  const client = !nativeCode.has(pkg.name) ? "только JS" : inExpoGo.has(pkg.name) ? "есть в Expo Go" : "нужен dev client";
  return `${pkg.name}: ${version}; ${client}`;
}

project.forEach((pkg) => console.log(price(pkg)));

const blockers = project.filter((pkg) => nativeCode.has(pkg.name) && !inExpoGo.has(pkg.name));
console.log(blockers.length === 0 ? "Expo Go хватит" : `Expo Go мало из-за: ${blockers.map((pkg) => pkg.name).join(", ")}`);

Расхождения бывают в обе стороны. react-native и react-native-screens в проекте старше закреплений. react-native-reanimated и @shopify/flash-list из npm, наоборот, новее — и для проверки Expo это такое же расхождение: последняя версия не значит подходящая. zustand SDK не знает, и ему не нужно: в пакете только JavaScript. А react-native-mmkv SDK не знает, нативная половина у него есть, а в Expo Go её нет — вместе с AppMetrica он и требует своей сборки.

Две верхние строки можно сверить с настоящим CLI. Переменная CI=1 нужна, чтобы команда только читала: без неё CLI в терминале спросит, не исправить ли версии сразу. В проекте автора, без сети:

CI=1 EXPO_OFFLINE=1 npx expo install --check

Те же два пакета и те же версии. А теперь та же команда с сетью:

CI=1 npx expo install --check

Четырнадцать строк вместо двух, и react-native теперь ждёт не 0.86.2, а 0.86.3. Причина — в исходнике @expo/cli 57.0.18, в функции getVersionedNativeModulesAsync. Без EXPO_OFFLINE CLI берёт список SDK с сервера Expo, а с ней — или если сервер не ответил — файл bundledNativeModules.json из установленного expo. Файл — снимок того патча, что стоит в проекте: 57.0.16 от 24.08.2026. Сервер — живой список, и на 14.09.2026 он знает патчи до expo 57.0.22. Поэтому функция выше, записанная по файлу, ждёт 0.86.2, а таблицы-снимки ниже пишут закрепления сервера — у react-native это 0.86.3.

Вопроса «работает ли пакет на новой архитектуре» среди трёх нет, и это не забыто. В React Native 0.86 старую архитектуру не включить — это видно в таблице «Что осталось от моста в 0.86», — поэтому в SDK 57 выбирать не из чего. Пометка «только новая архитектура» в README FlashList 2 и в ошибке Reanimated 4 — цена переезда для проекта на SDK 54: он держит React Native 0.81.5, последнюю линию, где старая архитектура ещё собиралась.

У функции есть и стена: в её данных нет поля peerDependencies. В этом поле пакет называет соседей, с которыми работает, но которых в себе не везёт; подробнее — в статье «Живой ли пакет», в вопросе о доле в нише. У react-native-reanimated 4.6.0 там записан react-native-worklets 0.12.x, а SDK 57 держит worklets 0.10.1. Поставить из npm одну библиотеку пары — значит разбить пару, и функция этого не заметит. Научить её — первая задача в конце статьи.

npm install меняет только JavaScript-половину. Всё, что пакет ищет в бинарнике, должно было попасть туда при сборке — в Expo Go его вшила команда Expo, в свою сборку вшиваете вы.

Что версии библиотек сообщества под SDK подбирает npx expo install, говорилось ещё в «Трёх этажах». Подбирать есть что: последняя версия в npm и версия, которую ждёт SDK, — разные числа. Вот как далеко на 14.09.2026 они разошлись у пакетов этой полки:

Отсюда три команды. Нативный пакет ставят npx expo install <пакет>: CLI допишет к имени версию из списка SDK. Расхождения в уже поставленном ищут npx expo install --check, как в прошлом разделе, а правят npx expo install --fix — оба флага есть в справке @expo/cli 57.0.18.

Две оговорки из исходника той же команды, функции getVersionedPackagesAsync. Версию, указанную руками, — npx expo install react-native-reanimated@4.7.1 — CLI не подменяет: верит вам. А пакет, которого в списке SDK нет, уходит менеджеру пакетов как есть, то есть последней версией из npm. Для такого пакета диапазон — ваш: проверять его на устройстве, помня, что старой архитектуры в SDK 57 нет, и держать запасной выход на случай, если пакет перестанет обновляться.

Закрепление меняется и внутри одного SDK. В файле expo 57.0.16 у react-native записано 0.86.2, а сервер для SDK 57 на 14.09.2026 отдаёт 0.86.3: номер SDK прежний, закрепление новое.

npm install ставит последнюю версию, npx expo install — ту, с которой собран ваш SDK. Для нативного пакета права вторая.

Начнём с темпа. В таблице — даты выпуска expo x.0.0 по реестру и версия React Native в списке каждого SDK на сервере Expo.

За год до снимка вышли три SDK, и каждый принёс новую линию React Native. Новый react-native — это новый бинарник: в таблице «Долетит или нужна сборка» правка «поднять react-native» меняет отпечаток. По воздуху такое обновление к установленным приложениям пускать нельзя — от этого их и бережёт замок из статьи «runtimeVersion: замок, который бережёт установленные приложения». А Expo Go из магазина собран под одну версию SDK («Свой проект»); на 14.09.2026 сервер Expo называет для него SDK 57.

SDK 58 уже виден: он в preview, и сервер Expo отдаёт его список. Что в нём ждёт пакеты этой полки:

curl -s https://api.expo.dev/v2/sdks/58.0.0/native-modules | node -e 'let s="";process.stdin.on("data",(d)=>(s+=d)).on("end",()=>{const m=Object.fromEntries(JSON.parse(s).data.map((i)=>[i.npmPackage,i.versionRange]));for(const p of ["react-native","react-native-gesture-handler","react-native-reanimated","react-native-keyboard-controller","@shopify/flash-list"])console.log(p,m[p]);})'

Список preview меняется на глазах: в тот же день, до выхода 58.0.0-preview.1, сервер отдавал для SDK 58 react-native 0.87.1, а теперь — кандидат в релиз 0.88.0-rc.0. Главная перемена для полки — react-native-gesture-handler ~3.2.1, новый мажор: по типам пакета 3.3.0 жесты в нём объявляются хуками вроде usePanGesture, а прежние объекты получили приставку Legacy — LegacyPanGesture, LegacyScrollView. Остальное — шаги внутри мажора: reanimated 4.6.0, keyboard-controller 1.22.4, а flash-list остаётся на 2.0.2.

Порядок обновления из этого и следует. Прочитать журнал изменений нового SDK — его адрес сервер Expo отдаёт сам, в поле releaseNoteUrl: у SDK 57 это expo.dev/changelog/sdk-57, а у SDK 58 в preview такого поля ещё нет. Поднять expo и выровнять остальное npx expo install --fix. Проверить проект целиком — для этого у Expo есть отдельный пакет expo-doctor: по описанию в реестре он ищет в проекте известные проблемы, запускается npx expo-doctor. Собрать новый dev client, проверить на устройстве — и только потом выпускать сборку и обновления к ней.

Пересмотреть, когда SDK 58 выйдет из preview: сверить закрепления всей полки.

Отдельная не нужна в проекте на Expo: expo-router уже в SDK. Он закреплён в SDK 57 и вшит в Expo Go, а React Navigation, на котором стоит, везёт внутри себя: в expo-router 57.0.21 это папка build/react-navigation. Пакетов @react-navigation/* в зависимостях у версий для SDK 56 и 57 нет, у версии для SDK 55 они были. Поэтому @react-navigation/native напрямую берут в React Native без Expo.

Своя сборка — глава 5: адрес из пути файла в «Собираем маршруты», история и системная «назад» в «Собираем стек экранов с историей» и сверка миниатюры с настоящим маршрутизатором — «Миниатюра остаётся в песочнице».

Тильда в версии — часть закрепления: SDK 57 принимает любой патч 57.0.x не ниже 24-го.

Пересмотреть с выходом SDK 58: сверить закрепление expo-router.

Не нужна для пары настроек: kv-store и SecureStore из SDK. Своя сборка: ящик строк по ключу, где каждый вызов — промис, в «Асинхронном ящике», а в разделе «Данные — в базе, токен — в SecureStore» — expo-sqlite/kv-store, замена AsyncStorage один в один, и expo-secure-store для токена.

На полке — kv-store и SecureStore. AsyncStorage остаётся там, где он уже стоит: SDK 57 и Expo Go держат 2.2.0 при 3.1.1 в npm, поэтому ставят его только через npx expo install.

react-native-mmkv — запас на случай, когда ящика строк мало. Синхронность сама по себе не довод: у kv-store тоже есть getItemSync. Довод — то, чего у kv-store нет: хук useMMKVString(key) перерисовывает компонент, когда значение по ключу меняется, а режим multi-process в спецификации пускает к тому же хранилищу расширения приложения и фоновые службы. Четвёртая версия построена на Nitro Modules — это отдельный нативный пакет react-native-nitro-modules того же автора, и mmkv 4.3.2 требует его в peerDependencies. Ни mmkv, ни nitro-modules нет ни в списке SDK 57, ни в Expo Go (проверено 14.09.2026), поэтому цена — своя сборка, а версия — ваша.

Пересмотреть, если SDK перейдёт на async-storage 3 или mmkv попадёт в Expo Go.

Не нужна, если данные живут на сервере: хватит кеша запросов. Если же главная копия в телефоне, своя сборка — главы 6 и 7: от «Главная копия — в телефоне» до настоящей базы в «expo-sqlite: настоящая база в телефоне», а сравнение готовых движков — в таблице «Что брать и чем платить».

Первый выбор — expo-sqlite из раздела выше: он в SDK и в Expo Go. @op-engineering/op-sqlite — запас на случай, когда упираетесь в скорость: в реестре он описывает себя как самый быстрый SQLite для React Native. Цена у него видна там же: распакованный пакет весит 351,7 миллиона байт. В архиве лежат исходники SQLite и SQLCipher, а для libsql и Turso — готовые библиотеки под каждую архитектуру Android и iOS.

PowerSync — запас для синхронизации с сервером. Нативная часть самого @powersync/react-native 2.2.1 маленькая — модуль PowerSyncOpSqlite для iOS и Android, — а база под ним — op-sqlite: в peerDependencies стоит @op-engineering/op-sqlite от 17.1.0 до 19. Та же строка «нативный код» есть в таблице движков.

Пересмотреть, если PowerSync сменит нативный драйвер или expo-sqlite получит синхронизацию.

Не нужны в local-first, где правда хранится в SQLite. Своя сборка — врезка «Кеш запросов — не движок синхронизации»: там TanStack Query из проекта автора настроен правильно, и там же видно, что его clear() в local-first стирает оригинал.

Если данные всё-таки живут на сервере — общий справочник упражнений, чужие программы тренировок, — полка та же, что в вебе. TanStack Query и Zustand — чистый JavaScript: в архивах @tanstack/react-query 5.102.8 и zustand 5.0.15 нет кода для iOS и Android, поэтому Expo Go им не помеха, а SDK их не закрепляет. Где у них стены и почему на полке именно они, разобрано на полке React и Next. В проекте автора стоят оба: @tanstack/react-query 5.102.3 и zustand 5.0.15.

Пересмотреть, если TanStack Query или Zustand выпустят v6.

Не нужна для простых переходов: Animated с useNativeDriver. Своя сборка — глава 8: значение, подписка и кадр в «Собираем анимацию», описание анимации во втором потоке в «useNativeDriver: два потока», функция в другом потоке в «Worklet: функция, уехавшая в другой поток» и то, почему сам Reanimated не запускается в предпросмотре, — «Почему Reanimated нет в предпросмотре».

Reanimated и worklets ставятся парой, и пару держит SDK. react-native-reanimated 4.5.1 просит в peerDependencies react-native-worklets 0.10.x, а 4.7.1 — уже 0.13.x (по реестру на 05.10.2026). npm install react-native-reanimated принесёт 4.7.1 к worklets 0.10.1 из SDK, и пара разбита. У gesture-handler в npm уже мажор 3, а ветка 2 живёт под тегом legacy: SDK 57 держит ~2.32.0, и хуков вроде usePanGesture в этой версии ещё нет.

Пересмотреть с выходом SDK 58: gesture-handler переходит на 3.

Не нужна, пока замер не показал проблем FlatList. Своя сборка: деление, распорки и запас в «Собираем окно», а счёт строк и вызовов — в таблице «Что на телефоне иначе», где песочница сверена с React Native 0.86.

FlashList 2 и LegendList 3 — чистый JavaScript: в архивах npm @shopify/flash-list 2.0.2 и 2.3.2 и @legendapp/list 3.3.11 нет ни ios/, ни android/, ни podspec (проверено 14.09.2026). Поэтому то, что FlashList нет в списке Expo Go, ему не мешает: вшивать нечего. Версию FlashList всё равно выбирает SDK, а LegendList SDK не знает, и его версия — ваша.

Пересмотреть, если SDK поднимет закрепление flash-list выше 2.0.2.

Не нужна камера, чтобы выбрать фото: хватит пикера. Своя сборка — «Настоящий Expo: пикер, файл и отправка»: пикер отвечает адресом файла, а в SDK 57 глобальный fetch — это expo/fetch, и часть формы { uri, name, type } он отклоняет.

Всё, кроме последней строки, — модули SDK, и в Expo Go они уже есть. Но и им нужен npx expo install: тег latest в npm живёт своей жизнью, а закрепление SDK — своей (на 14.09.2026 latest у expo-camera стоял на 57.0.4, ниже закрепления, к 05.10.2026 догнал его). expo-av в этом списке больше нет: его убрали из SDK 55, и звук с видео теперь у expo-audio и expo-video — подробнее в разделе «Сошли с полки».

VisionCamera — запас для случая, когда нужны сами кадры: у react-native-vision-camera 5.2.3 есть useFrameOutput и тип Frame. Как и mmkv, пятая версия стоит на Nitro Modules — в её peerDependencies react-native-nitro-modules и react-native-nitro-image, — а в SDK её нет, так что и цена та же: своя сборка.

Пересмотреть с выходом SDK 58: сверить закрепления expo-image-picker, expo-camera, expo-image, expo-audio и expo-video.

Не нужна для одного поля: KeyboardAvoidingView. Своя сборка — «Клавиатура — ещё один нижний край»: события Keyboard, расчёт сдвига по исходнику KeyboardAvoidingView и правило, что отступ клавиатуры и отступ безопасной зоны не складывают.

react-native-keyboard-controller есть и в SDK 57, и в Expo Go, так что цена у него только в соседях: в peerDependencies стоит react-native-reanimated не ниже 3.0.0. Reanimated в SDK тоже есть, и npx expo install поставит обоих в версиях одного SDK.

Пересмотреть с выходом SDK 58: его список уже держит 1.22.4.

Эти пакеты ещё встречаются в старых проектах и ответах на форумах. У каждого — дата последнего выпуска, номер вопроса из «Живой ли пакет», на котором он отсеялся, и что брать вместо. Номера те же: 0 — не умеет ли этого платформа, 1 — жив ли пакет. На телефоне платформа — это и SDK Expo.

WatermelonDB сошёл с полки, но не из учебника: его разбор в статье «Готовые движки: WatermelonDB и PowerSync» остаётся, и читать его стоит как устройство движка синхронизации, а не как совет, что ставить.

Сошедший пакет не обязательно выкорчёвывать завтра. Но новый код на нём не пишут, а при переходе на новый SDK его меняют первым.

Пакеты ниже живы и не помечены устаревшими. Отказ — не оценка качества. У двух первых это вопрос 4 из «Живой ли пакет»: навязывает ли пакет устройство проекта. Оговорка та же, что на полке React и Next: вопрос 4 совпадает с укладом автора — стили здесь пишутся через StyleSheet.create, — поэтому у каждой строки названа причина, которую можно проверить.

Строка аналитики отличается от остальных: отказ здесь не пакету, а паспорту. Ставить ли SDK аналитики, решает продукт, а полка может только назвать цену: нативная половина вне Expo Go и данные пользователей на чужом сервере.

Вопрос 4 не запрещает пакет. Он предупреждает, что уйти с него — значит переписать экраны, а не поменять строку в package.json.