Fix/mobile tsconfig path aliases - #586
Conversation
…e .well-known files for passkeys
…C_RP_ID / NEXT_PUBLIC_ORIGIN)
|
@rhoggs-bot-test-account is attempting to deploy a commit to the miracle656's projects Team on Vercel. A member of the Team first needs to authorize it. |
|
@Davoski1 Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits. You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀 |
|
Please rebase onto |
|
Thanks @Davoski1 — reviewed. Mixed after the config migration:
Could you close this and open a focused PR for just the |
|
Apologies — this sat unreviewed for a month while What happened: PR #508 (
And the domain-association files are now hosted for real, not as examples: So the gap you were closing is closed. I have checked Specific to this PR: the This PR is also cumulative over #585 and #584 (6 files ⊃ 5 ⊃ 3), so all three are in the same position. Not closing it — your call. Sorry the wait made it moot; the tsconfig instinct was right, it just got there via another PR. |
…ath-aliases # Conflicts: # frontend/wallet/lib/network.ts
Miracle656
left a comment
Miracle656
left a comment
There was a problem hiding this comment.
Approved and merging — rebased on your branch (b40c303) and reduced to the tsconfig change this PR is named for.
Aligning @/* with ./* is right, and it matches what frontend/wallet already does. @/* → ./app/* is a slightly odd mapping to have: it makes the root alias mean the routes directory specifically, so @/lib/foo and @/hooks/foo silently fail to resolve while @/components/foo works only because there is a separate, more specific mapping for it.
I checked what actually depends on this before merging, because a path-alias change is the kind of thing that either does nothing or breaks the build. Exactly one @/ import exists in the mobile app today — @/components/ScreenScaffold — and it resolves through the dedicated @/components/* entry, which is more specific and wins either way. So this is a no-op on current code and unblocks the conventional @/lib/... form going forward.
Verified: tsc --noEmit -p tsconfig.typecheck.json clean, 430 tests across 28 suites passing. QuickActions.test.tsx fails, but identically on main — I checked out main and re-ran rather than assuming.
What I dropped: frontend/wallet/lib/network.ts, examples/nextjs/src/lib/network.ts, frontend/mobile/app.config.js and examples/expo/.well-known/* — all carried from your #584 and #585, both of which are now merged. The rpId/origin config landed via #585; the Expo config and .well-known files were superseded by main's app.config.ts and the real files under frontend/wallet/public/, with the reasoning on #584.
That's all three of your PRs in. Thanks — #584 in particular surfaced a genuine iOS passkey bug.
The dev client died at launch with:
Unable to start activity ComponentInfo{xyz.veil.wallet/.MainActivity}:
java.lang.IllegalArgumentException: App react context shouldn't be created before.
at DevLauncherAppLoader.createOnDelegateWillBeCreatedListener(DevLauncherAppLoader.kt:49)
Cause: expo-notifications was pinned ^57.0.15 while Expo SDK 54 expects
~0.32.17 -- and unlike every other expo-* dependency here it used a caret, so
it drifted a major version off the SDK. It then bundled its own nested copies
of expo-application@57.0.2 and expo-constants@57.0.15, so the APK contained two
versions of the same native modules. Two Expo module registries means the React
context gets created twice, which is exactly what expo-dev-launcher refuses.
expo-doctor named it once asked:
Major version mismatches
package expected found
expo-notifications ~0.32.17 57.0.15
Fixed with , which resolves the SDK-matched
version. The nested expo-application / expo-constants duplicates are gone with
it.
Two related metro.config.js fixes while here:
- now maps to the project root, matching tsconfig. #586 widened from
./app/* to ./* but metro still pointed at app/, so an import
would typecheck and then fail to resolve at runtime -- invisible to CI,
because tsc is the only thing that reads tsconfig. That divergence is mine,
from merging #586 without following it through here.
- react and react-dom are pinned to the app's own copy. Since #670 made each
package install independently, sdk/node_modules carries react@19.2.8 against
the app's 19.1.0, and metro follows the symlink into sdk/ to read its
sources. Two Reacts in one bundle gives two hook dispatchers, surfacing as
'Invalid hook call' from correct code.
Verified: expo-doctor's SDK-version and duplicate-native-module checks now
pass, metro.config.js loads with both aliases resolving as intended, tsc clean,
430 tests across 28 suites (QuickActions.test.tsx fails identically on main).
The dev client died at launch with:
Unable to start activity ComponentInfo{xyz.veil.wallet/.MainActivity}:
java.lang.IllegalArgumentException: App react context shouldn't be created before.
at DevLauncherAppLoader.createOnDelegateWillBeCreatedListener(DevLauncherAppLoader.kt:49)
Cause: expo-notifications was pinned ^57.0.15 while Expo SDK 54 expects
~0.32.17 -- and unlike every other expo-* dependency here it used a caret, so
it drifted a major version off the SDK. It then bundled its own nested copies
of expo-application@57.0.2 and expo-constants@57.0.15, so the APK contained
two versions of the same native modules. Two Expo module registries means the
React context gets created twice, which is exactly what expo-dev-launcher
refuses.
expo-doctor named it once asked:
Major version mismatches
package expected found
expo-notifications ~0.32.17 57.0.15
Fixed with "expo install expo-notifications", which resolves the SDK-matched
version. The nested expo-application / expo-constants duplicates go with it.
Two related metro.config.js fixes while here:
- "@" now maps to the project root, matching tsconfig. #586 widened "@/*" from
./app/* to ./* but metro still pointed at app/, so an "@/lib/foo" import
would typecheck and then fail to resolve at runtime -- invisible to CI,
because tsc is the only thing that reads tsconfig. That divergence is mine,
from merging #586 without following it through here.
- react and react-dom are pinned to the app's own copy. Since #670 made each
package install independently, sdk/node_modules carries react@19.2.8 against
the app's 19.1.0, and metro follows the symlink into sdk/ to read its
sources. Two Reacts in one bundle gives two hook dispatchers, surfacing as
"Invalid hook call" from code that is perfectly correct.
Verified: expo-doctor's SDK-version and duplicate-native-module checks now
pass, metro.config.js loads with both aliases resolving as intended, tsc
clean, 430 tests across 28 suites (QuickActions.test.tsx fails identically on
main).
2 participants
Summary
Configure the mobile TypeScript project to use the same
@/path alias as the web wallet by mapping"@/*": ["./*"]. This makes imports consistent across mobile and web and prevents import/type errors when moving code between the apps.Changes
frontend/mobile/tsconfig.json:"@/*"path mapping from["./app/*"]to["./*"]."@/assets/*": ["./assets/*"]mapping.Why
The web wallet uses
"@/*": ["./*"], but the mobile app previously mapped@/*only to./app/*. That made many@/...imports resolve differently on mobile vs web, causing type and resolution issues. Unifying the alias improves developer ergonomics and CI consistency.Testing / Verification
tsc --noEmitin thefrontend/mobileworkspace (or rely on CI) to verify no resolution/type errors.Closes 9. tsconfig + path aliases #437