Describe the bug
When a registry item declares a bare Expo dependency, shadcn should let
expo install choose the version compatible with the project's Expo SDK.
This worked in shadcn@4.13.0, but regressed in 4.13.1.
Using the same registry item in two identical Expo SDK 56 projects:
| CLI |
Installed @expo/ui |
expo install --check |
shadcn@4.13.0 |
~56.0.23 |
Passes |
shadcn@4.13.1 |
^57.0.7 |
Fails |
The failing project reports:
@expo/ui@57.0.7 - expected version: ~56.0.23
Found outdated dependencies
This was introduced in #11195 when the Expo command changed from:
npx expo install <dependencies>
to:
npx expo install -- <dependencies>
Expo passes arguments after -- directly to the package manager, so those
dependencies skip Expo's SDK version resolution.
The obvious fix is to remove -- only from Expo's normal dependency path.
However, #11195 intentionally added two layers of protection: the
assertSafeDependencies guard and the end-of-options separator. Removing the
separator would preserve the guard but reduce Expo's path to one layer.
I have not opened a PR because this changes the defense-in-depth design from
#11195. I would like maintainer guidance on whether the guard alone is
acceptable for Expo or whether a different approach is preferred.
Affected component/components
shadcn CLI, Expo dependency installation
How to reproduce
Complete reproduction:
https://github.com/brilliantinsane/shadcn-expo-sdk-resolution-repro/tree/6ca2bece27dea2ecbe81fadd463148aec0935132
The repository contains one Expo SDK 56 template and the completed results from
running the same registry item with shadcn@4.13.0 and shadcn@4.13.1.
The registry input is generic and pinned to a commit:
https://github.com/brilliantinsane/shadcn-expo-registry-fixture/blob/ad2d88d0a3468c6d506fe8d58191ed35cbb7a2da/registry.json
Codesandbox/StackBlitz link
https://github.com/brilliantinsane/shadcn-expo-sdk-resolution-repro/tree/6ca2bece27dea2ecbe81fadd463148aec0935132
System Info
Expo: 56.0.17
React Native: 0.85.3
Package manager: pnpm 11.11.0
Unaffected shadcn version: 4.13.0
Affected shadcn version: 4.13.1
Before submitting
Describe the bug
When a registry item declares a bare Expo dependency, shadcn should let
expo installchoose the version compatible with the project's Expo SDK.This worked in
shadcn@4.13.0, but regressed in4.13.1.Using the same registry item in two identical Expo SDK 56 projects:
@expo/uiexpo install --checkshadcn@4.13.0~56.0.23shadcn@4.13.1^57.0.7The failing project reports:
This was introduced in #11195 when the Expo command changed from:
to:
Expo passes arguments after
--directly to the package manager, so thosedependencies skip Expo's SDK version resolution.
The obvious fix is to remove
--only from Expo's normal dependency path.However, #11195 intentionally added two layers of protection: the
assertSafeDependenciesguard and the end-of-options separator. Removing theseparator would preserve the guard but reduce Expo's path to one layer.
I have not opened a PR because this changes the defense-in-depth design from
#11195. I would like maintainer guidance on whether the guard alone is
acceptable for Expo or whether a different approach is preferred.
Affected component/components
shadcn CLI, Expo dependency installation
How to reproduce
Complete reproduction:
https://github.com/brilliantinsane/shadcn-expo-sdk-resolution-repro/tree/6ca2bece27dea2ecbe81fadd463148aec0935132
The repository contains one Expo SDK 56 template and the completed results from
running the same registry item with
shadcn@4.13.0andshadcn@4.13.1.The registry input is generic and pinned to a commit:
https://github.com/brilliantinsane/shadcn-expo-registry-fixture/blob/ad2d88d0a3468c6d506fe8d58191ed35cbb7a2da/registry.json
Codesandbox/StackBlitz link
https://github.com/brilliantinsane/shadcn-expo-sdk-resolution-repro/tree/6ca2bece27dea2ecbe81fadd463148aec0935132
System Info
Before submitting