From 6d31eeda213cee91576b6b5cb23fc0ddea66e810 Mon Sep 17 00:00:00 2001 From: Claude Date: Wed, 28 Oct 2026 14:17:21 +0000 Subject: [PATCH 1/2] docs(expo): name clerk-ios 1.6.2 as the release the Expo verify skill describes The podspec pins clerk-ios 1.6.2 since #10457, but the feature map still named 1.6.1 in three places. Co-Authored-By: Claude Opus 5.5 Claude-Session: https://claude.ai/code/session_01WtSUsr2bQHRBPVkDbpNPnm --- .changeset/verify-expo-clerk-ios-pin.md | 2 ++ .claude/skills/verify-clerk-expo/features/README.md | 4 ++-- .claude/skills/verify-clerk-expo/features/native-auth-view.md | 2 +- 3 files changed, 5 insertions(+), 3 deletions(-) create mode 100644 .changeset/verify-expo-clerk-ios-pin.md diff --git a/.changeset/verify-expo-clerk-ios-pin.md b/.changeset/verify-expo-clerk-ios-pin.md new file mode 100644 index 00000000000..a845151cc84 --- /dev/null +++ b/.changeset/verify-expo-clerk-ios-pin.md @@ -0,0 +1,2 @@ +--- +--- diff --git a/.claude/skills/verify-clerk-expo/features/README.md b/.claude/skills/verify-clerk-expo/features/README.md index 78f1fc47c02..607dba9c737 100644 --- a/.claude/skills/verify-clerk-expo/features/README.md +++ b/.claude/skills/verify-clerk-expo/features/README.md @@ -32,7 +32,7 @@ This directory is the maintained source for verifying the user-facing behavior o | Sign-up code field | `clerk.auth.signUp.code` | `verify.customSignUp.code`, then `verify.customSignUp.verifyCode` | | Close AuthView | `clerk.dismissButton` | none | -The iOS identifiers come from `Sources/ClerkKitUI/Components/Auth/ClerkAccessibilityIdentifiers.swift` in the clerk-ios release that `packages/expo-native-components/ios/ClerkExpo.podspec` pins, which is 1.6.1. The Android names are the same, from `ClerkTestTags` in the clerk-android release that `packages/expo-native-components/android/build.gradle` pins, which is 1.3.0. That release sets them as resource ids on AuthView and UserProfileView. Android specs still find native views by their text. The custom-flow testIDs live in `integration/templates/expo-native/screens/`. +The iOS identifiers come from `Sources/ClerkKitUI/Components/Auth/ClerkAccessibilityIdentifiers.swift` in the clerk-ios release that `packages/expo-native-components/ios/ClerkExpo.podspec` pins, which is 1.6.2. The Android names are the same, from `ClerkTestTags` in the clerk-android release that `packages/expo-native-components/android/build.gradle` pins, which is 1.3.0. That release sets them as resource ids on AuthView and UserProfileView. Android specs still find native views by their text. The custom-flow testIDs live in `integration/templates/expo-native/screens/`. ## Driving conventions @@ -61,4 +61,4 @@ Each feature file starts with an H1 title and one paragraph describing the user- Not mapped yet: SSO through `useSSO` (no real OAuth on simulators), a Google or Apple native sign-in with a real account, passkeys, enrolling or using a biometric (no associated domains or Secure Enclave on the simulator), and session tasks in the native views. -Organizations have no page, because a user of the test app has no way to reach organization UI. This holds for the native components only. `@clerk/expo/web` exports the clerk-js OrganizationProfile, OrganizationSwitcher, OrganizationList, and CreateOrganization for Expo web, but the test app runs native only. `@clerk/expo-native-components` exports AuthView, UserButton, and UserProfileView and no OrganizationSwitcher or OrganizationProfileView. The profile that the UserButton opens lists `Manage account`, `Security`, `Add account`, and `Sign out`, with `Switch account` once a second session exists, and no organization row, in clerk-ios 1.6.1 and clerk-android 1.3.0, though the standard settings turn organizations on. The one organization screen that a native view shows is a session task in AuthView, choose or create an organization, which needs `force_organization_selection` on. The harness seeds users, sign-in tickets, and, through `host.seedOrganization`, organizations whose members hold one of the harness roles. It cannot seed invitations, so no spec can reach a choose-organization task that lists an invitation. Today such a state can be shown only with a local patch that is not committed, and the description of the pull request that shows it says so. +Organizations have no page, because a user of the test app has no way to reach organization UI. This holds for the native components only. `@clerk/expo/web` exports the clerk-js OrganizationProfile, OrganizationSwitcher, OrganizationList, and CreateOrganization for Expo web, but the test app runs native only. `@clerk/expo-native-components` exports AuthView, UserButton, and UserProfileView and no OrganizationSwitcher or OrganizationProfileView. The profile that the UserButton opens lists `Manage account`, `Security`, `Add account`, and `Sign out`, with `Switch account` once a second session exists, and no organization row, in clerk-ios 1.6.2 and clerk-android 1.3.0, though the standard settings turn organizations on. The one organization screen that a native view shows is a session task in AuthView, choose or create an organization, which needs `force_organization_selection` on. The harness seeds users, sign-in tickets, and, through `host.seedOrganization`, organizations whose members hold one of the harness roles. It cannot seed invitations, so no spec can reach a choose-organization task that lists an invitation. Today such a state can be shown only with a local patch that is not committed, and the description of the pull request that shows it says so. diff --git a/.claude/skills/verify-clerk-expo/features/native-auth-view.md b/.claude/skills/verify-clerk-expo/features/native-auth-view.md index 94b180525b0..87c0df1556e 100644 --- a/.claude/skills/verify-clerk-expo/features/native-auth-view.md +++ b/.claude/skills/verify-clerk-expo/features/native-auth-view.md @@ -36,7 +36,7 @@ Preconditions: - On iOS AuthView renders inline, where SwiftUI's `dismiss` has no effect, so `@clerk/expo-native-components` calls `onDismiss` from the close button itself. That holds for the full-screen AuthView and for the one in the home's modal, which the home closes from that `onDismiss`. The modal's `onRequestClose` handles only the Android back button and an iOS swipe down. The `dismiss` test covers the full-screen close button, and `close-modal` covers the modal's. - clerk-ios AuthView remembers the last identifier in UserDefaults. The test app clears it on every new storage scope, so the field starts empty. A prefilled field shows as two `clerk.auth.start.identifier` nodes (label and textbox) and fails a locator with `LOCATOR_AMBIGUOUS`. If that happens, the test app's scope clearing regressed. -- `@clerk/expo-native-components` ships the clerk-ios release pinned in `packages/expo-native-components/ios/ClerkExpo.podspec` (1.6.1), so iOS has the `clerk.auth.*` identifiers. It ships clerk-android 1.3.0, pinned in `packages/expo-native-components/android/build.gradle`. That release sets the same `clerk.*` names as resource ids on AuthView. Android specs still find AuthView by its text (`Enter your email or username`, `Continue`), in `specs/native.ts`. Switch those locators to `getByTestId` once a run shows the resource ids in the screen tree. +- `@clerk/expo-native-components` ships the clerk-ios release pinned in `packages/expo-native-components/ios/ClerkExpo.podspec` (1.6.2), so iOS has the `clerk.auth.*` identifiers. It ships clerk-android 1.3.0, pinned in `packages/expo-native-components/android/build.gradle`. That release sets the same `clerk.*` names as resource ids on AuthView. Android specs still find AuthView by its text (`Enter your email or username`, `Continue`), in `specs/native.ts`. Switch those locators to `getByTestId` once a run shows the resource ids in the screen tree. - The test app puts nothing above, below, or over AuthView. On iOS the screen tree leaves out what a modal covers, so the home's nodes are not in the tree while the modal AuthView is up. - On Android, an AuthView that can be dismissed shows a close button with the label `Close`, and `Sign in full screen` shows none. No spec taps that button. The back button closes the AuthView that the home opened. - The standard settings have the email link off, because a test address gets no mail, so a run has no link to follow. With the link on, AuthView opens the email link screen first (`Open email app`), which has no code field, and a spec that expects `clerk.auth.signIn.code` right after Continue times out. A spec that needs the link declares `auth_email.sign_in_strategies` in a settings file. From 6203e6c4560835d3582ba4e6795e21ac4fb0fe46 Mon Sep 17 00:00:00 2001 From: Claude Date: Wed, 28 Oct 2026 15:04:37 +0000 Subject: [PATCH 2/2] docs(expo): point the Expo verify skill at the SDK pins instead of naming versions The skill named the clerk-ios and clerk-android releases that @clerk/expo-native-components pins, so every SDK bump left it wrong. It now names the podspec and build.gradle that hold the pins. Co-Authored-By: Claude Opus 5.5 Claude-Session: https://claude.ai/code/session_01WtSUsr2bQHRBPVkDbpNPnm --- .claude/skills/verify-clerk-expo/SKILL.md | 2 +- .claude/skills/verify-clerk-expo/features/README.md | 6 +++--- .../skills/verify-clerk-expo/features/native-auth-view.md | 2 +- 3 files changed, 5 insertions(+), 5 deletions(-) diff --git a/.claude/skills/verify-clerk-expo/SKILL.md b/.claude/skills/verify-clerk-expo/SKILL.md index 8e720d75d2b..3b300b41e52 100644 --- a/.claude/skills/verify-clerk-expo/SKILL.md +++ b/.claude/skills/verify-clerk-expo/SKILL.md @@ -154,7 +154,7 @@ The test app shows the home again when a full-screen AuthView or a custom form c The test app has a screen or a small flow of its own only where the native views cannot prove a thing. The custom sign-in and sign-up forms drive `useSignIn` and `useSignUp`. The test app reads the `@clerk/expo` token cache once, as the app starts and before Clerk has loaded, and the `Token cache` screen says whether a client token was kept from the last launch. `Sign in with a logo` opens the home's modal AuthView with a React Native view as its `logo`. The `Embedded profile` screen is UserProfileView inline with one custom page, `isDismissible={false}`, and `onHostBack`. The `Native modules` screen has one button for `useSignInWithGoogle` and one for `useBiometricCredentials`, each with its result as text. The test app looks and behaves as an app does for a real user. When a change needs a flow that no native view covers, add a screen that a real app would have, and assert on the outcome as a user sees it. -On iOS, locate nodes of the native views with the SDK's identifiers, such as `screen.getByTestId('clerk.auth.start.identifier')`. The clerk-android release that `@clerk/expo-native-components` pins, 1.3.0, sets the same `clerk.*` names as resource ids, but `specs/native.ts` still finds the Android native views by text. The home has `e2e.*` testIDs, which `host.app` holds, and the test app's other screens have `verify.*` testIDs, on both platforms. All of these identifiers are internal test hooks, not public API, and they can change. Every spec keeps at least one exact assertion on an identifier or on visible text. To assert on the text of a node, use `await expect(locator).toHaveText('...')`. +On iOS, locate nodes of the native views with the SDK's identifiers, such as `screen.getByTestId('clerk.auth.start.identifier')`. The clerk-android release that `@clerk/expo-native-components` pins sets the same `clerk.*` names as resource ids, but `specs/native.ts` still finds the Android native views by text. The home has `e2e.*` testIDs, which `host.app` holds, and the test app's other screens have `verify.*` testIDs, on both platforms. All of these identifiers are internal test hooks, not public API, and they can change. Every spec keeps at least one exact assertion on an identifier or on visible text. To assert on the text of a node, use `await expect(locator).toHaveText('...')`. A spec file that needs other settings than the standard ones has a settings file beside it, with the same name and `.settings.json` in place of `.e2e.ts`. `run` puts the application on those settings before the tests in that spec file start. Any other JSON file under `specs/` stops every run. [Test instances](references/instances.md) has the rules for a declaration. diff --git a/.claude/skills/verify-clerk-expo/features/README.md b/.claude/skills/verify-clerk-expo/features/README.md index 607dba9c737..8e453cdce32 100644 --- a/.claude/skills/verify-clerk-expo/features/README.md +++ b/.claude/skills/verify-clerk-expo/features/README.md @@ -32,11 +32,11 @@ This directory is the maintained source for verifying the user-facing behavior o | Sign-up code field | `clerk.auth.signUp.code` | `verify.customSignUp.code`, then `verify.customSignUp.verifyCode` | | Close AuthView | `clerk.dismissButton` | none | -The iOS identifiers come from `Sources/ClerkKitUI/Components/Auth/ClerkAccessibilityIdentifiers.swift` in the clerk-ios release that `packages/expo-native-components/ios/ClerkExpo.podspec` pins, which is 1.6.2. The Android names are the same, from `ClerkTestTags` in the clerk-android release that `packages/expo-native-components/android/build.gradle` pins, which is 1.3.0. That release sets them as resource ids on AuthView and UserProfileView. Android specs still find native views by their text. The custom-flow testIDs live in `integration/templates/expo-native/screens/`. +The iOS identifiers come from `Sources/ClerkKitUI/Components/Auth/ClerkAccessibilityIdentifiers.swift` in the clerk-ios release that `packages/expo-native-components/ios/ClerkExpo.podspec` pins. The Android names are the same, from `ClerkTestTags` in the clerk-android release that `packages/expo-native-components/android/build.gradle` pins. That release sets them as resource ids on AuthView and UserProfileView. Android specs still find native views by their text. The custom-flow testIDs live in `integration/templates/expo-native/screens/`. ## Driving conventions -- Prefer SDK identifiers on iOS and test app testIDs everywhere. `specs/native.ts` holds the per-platform locators. On Android those locators still match native Clerk views by text, including where clerk-android 1.3.0 has a `clerk.*` resource id. +- Prefer SDK identifiers on iOS and test app testIDs everywhere. `specs/native.ts` holds the per-platform locators. On Android those locators still match native Clerk views by text, including where the pinned clerk-android release has a `clerk.*` resource id. - Look first in the native view on the spec's path: the AuthView code screen, or the profile and its `Manage account` screen. Use the `Token cache` screen for what the token cache held when the app started. ## Proof and skip reporting @@ -61,4 +61,4 @@ Each feature file starts with an H1 title and one paragraph describing the user- Not mapped yet: SSO through `useSSO` (no real OAuth on simulators), a Google or Apple native sign-in with a real account, passkeys, enrolling or using a biometric (no associated domains or Secure Enclave on the simulator), and session tasks in the native views. -Organizations have no page, because a user of the test app has no way to reach organization UI. This holds for the native components only. `@clerk/expo/web` exports the clerk-js OrganizationProfile, OrganizationSwitcher, OrganizationList, and CreateOrganization for Expo web, but the test app runs native only. `@clerk/expo-native-components` exports AuthView, UserButton, and UserProfileView and no OrganizationSwitcher or OrganizationProfileView. The profile that the UserButton opens lists `Manage account`, `Security`, `Add account`, and `Sign out`, with `Switch account` once a second session exists, and no organization row, in clerk-ios 1.6.2 and clerk-android 1.3.0, though the standard settings turn organizations on. The one organization screen that a native view shows is a session task in AuthView, choose or create an organization, which needs `force_organization_selection` on. The harness seeds users, sign-in tickets, and, through `host.seedOrganization`, organizations whose members hold one of the harness roles. It cannot seed invitations, so no spec can reach a choose-organization task that lists an invitation. Today such a state can be shown only with a local patch that is not committed, and the description of the pull request that shows it says so. +Organizations have no page, because a user of the test app has no way to reach organization UI. This holds for the native components only. `@clerk/expo/web` exports the clerk-js OrganizationProfile, OrganizationSwitcher, OrganizationList, and CreateOrganization for Expo web, but the test app runs native only. `@clerk/expo-native-components` exports AuthView, UserButton, and UserProfileView and no OrganizationSwitcher or OrganizationProfileView. The profile that the UserButton opens lists `Manage account`, `Security`, `Add account`, and `Sign out`, with `Switch account` once a second session exists, and no organization row, in the pinned clerk-ios and clerk-android releases, though the standard settings turn organizations on. The one organization screen that a native view shows is a session task in AuthView, choose or create an organization, which needs `force_organization_selection` on. The harness seeds users, sign-in tickets, and, through `host.seedOrganization`, organizations whose members hold one of the harness roles. It cannot seed invitations, so no spec can reach a choose-organization task that lists an invitation. Today such a state can be shown only with a local patch that is not committed, and the description of the pull request that shows it says so. diff --git a/.claude/skills/verify-clerk-expo/features/native-auth-view.md b/.claude/skills/verify-clerk-expo/features/native-auth-view.md index 87c0df1556e..29fb9a4fc8c 100644 --- a/.claude/skills/verify-clerk-expo/features/native-auth-view.md +++ b/.claude/skills/verify-clerk-expo/features/native-auth-view.md @@ -36,7 +36,7 @@ Preconditions: - On iOS AuthView renders inline, where SwiftUI's `dismiss` has no effect, so `@clerk/expo-native-components` calls `onDismiss` from the close button itself. That holds for the full-screen AuthView and for the one in the home's modal, which the home closes from that `onDismiss`. The modal's `onRequestClose` handles only the Android back button and an iOS swipe down. The `dismiss` test covers the full-screen close button, and `close-modal` covers the modal's. - clerk-ios AuthView remembers the last identifier in UserDefaults. The test app clears it on every new storage scope, so the field starts empty. A prefilled field shows as two `clerk.auth.start.identifier` nodes (label and textbox) and fails a locator with `LOCATOR_AMBIGUOUS`. If that happens, the test app's scope clearing regressed. -- `@clerk/expo-native-components` ships the clerk-ios release pinned in `packages/expo-native-components/ios/ClerkExpo.podspec` (1.6.2), so iOS has the `clerk.auth.*` identifiers. It ships clerk-android 1.3.0, pinned in `packages/expo-native-components/android/build.gradle`. That release sets the same `clerk.*` names as resource ids on AuthView. Android specs still find AuthView by its text (`Enter your email or username`, `Continue`), in `specs/native.ts`. Switch those locators to `getByTestId` once a run shows the resource ids in the screen tree. +- `@clerk/expo-native-components` ships the clerk-ios release pinned in `packages/expo-native-components/ios/ClerkExpo.podspec`, so iOS has the `clerk.auth.*` identifiers. It ships the clerk-android release pinned in `packages/expo-native-components/android/build.gradle`. That release sets the same `clerk.*` names as resource ids on AuthView. Android specs still find AuthView by its text (`Enter your email or username`, `Continue`), in `specs/native.ts`. Switch those locators to `getByTestId` once a run shows the resource ids in the screen tree. - The test app puts nothing above, below, or over AuthView. On iOS the screen tree leaves out what a modal covers, so the home's nodes are not in the tree while the modal AuthView is up. - On Android, an AuthView that can be dismissed shows a close button with the label `Close`, and `Sign in full screen` shows none. No spec taps that button. The back button closes the AuthView that the home opened. - The standard settings have the email link off, because a test address gets no mail, so a run has no link to follow. With the link on, AuthView opens the email link screen first (`Open email app`), which has no code field, and a spec that expects `clerk.auth.signIn.code` right after Continue times out. A spec that needs the link declares `auth_email.sign_in_strategies` in a settings file.