Add an internal Expo-project marker to the Uniwind Metro config and use it to lazily choose the correct transform worker.#593
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (3)
🚧 Files skipped from review as they are similar to previous changes (2)
📝 WalkthroughWalkthroughThe Metro adapter now records whether a config uses Expo’s transformer path, passes that flag through Uniwind’s Metro config, and selects the transform worker lazily per call with caching. ChangesMetro Transformer Worker Selection
Estimated code review effort: 2 (Simple) | ~10 minutes Possibly related PRs
Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Greptile SummaryThis PR updates Uniwind's Metro integration to choose the right transform worker for Expo and plain React Native projects. The main changes are:
Confidence Score: 5/5This looks safe to merge.
Important Files Changed
Reviews (2): Last reviewed commit: "fix(metro): harden transform worker sele..." | Re-trigger Greptile |
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
🧹 Nitpick comments (1)
packages/uniwind/src/bundler/adapters/metro/transformer.ts (1)
12-34: 🩺 Stability & Availability | 🔵 Trivial | 💤 Low valueCache not keyed by
isExpoProject.
getTransformWorkercaches the first resolved worker in the module-levelworkervariable regardless of theisExpoProjectvalue on subsequent calls. This is fine as long as one Metro process only ever transforms files for a single project/config, but if this transformer module is ever reused across configs with differingisExpoProjectwithin the same process, the stale cached worker would be returned — the same class of bug this PR is fixing.♻️ Defensive fix: key the cache by isExpoProject
-let worker: typeof MetroTransformWorker | undefined +const workerCache = new Map<boolean, typeof MetroTransformWorker>() const getTransformWorker = (isExpoProject?: boolean): typeof MetroTransformWorker => { - if (worker) { - return worker + const cacheKey = Boolean(isExpoProject) + const cached = workerCache.get(cacheKey) + if (cached) { + return cached } const resolvedWorker: typeof MetroTransformWorker = isExpoProject ? (() => { try { const { unstable_transformerPath } = require('`@expo/metro-config`') as typeof ExpoMetroConfig return require(unstable_transformerPath) } catch { return require('`@expo/metro-config/build/transform-worker/transform-worker.js`') } })() : require('metro-transform-worker') - worker = resolvedWorker + workerCache.set(cacheKey, resolvedWorker) return resolvedWorker }Please confirm whether a single Node process can host Metro transforms for multiple projects/configs in this monorepo's build tooling (e.g. programmatic multi-target builds); if not, this is purely defensive.
Also applies to: 45-45
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@packages/uniwind/src/bundler/adapters/metro/transformer.ts` around lines 12 - 34, The module-level cache in getTransformWorker is not keyed by isExpoProject, so a worker resolved for one project type can be incorrectly reused for another. Update getTransformWorker in transformer.ts to cache separate resolved workers for Expo and non-Expo calls (or otherwise key the cache by isExpoProject) while keeping the existing lazy resolution logic around MetroTransformWorker and ExpoMetroConfig.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Nitpick comments:
In `@packages/uniwind/src/bundler/adapters/metro/transformer.ts`:
- Around line 12-34: The module-level cache in getTransformWorker is not keyed
by isExpoProject, so a worker resolved for one project type can be incorrectly
reused for another. Update getTransformWorker in transformer.ts to cache
separate resolved workers for Expo and non-Expo calls (or otherwise key the
cache by isExpoProject) while keeping the existing lazy resolution logic around
MetroTransformWorker and ExpoMetroConfig.
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: a8917567-d31c-4cee-aae9-59ce3844ca9f
📒 Files selected for processing (4)
CONTEXT.mdpackages/uniwind/src/bundler/adapters/metro/metro.tspackages/uniwind/src/bundler/adapters/metro/transformer.tspackages/uniwind/src/bundler/types.ts
| type ExpoTransformerConfig = NonNullable<MetroConfig['transformer']> & { | ||
| _expoRelativeProjectRoot?: string | ||
| _expoRouterPath?: string | ||
| expo_customTransformerPath?: string | false | ||
| postcssHash?: string | null | ||
| } | ||
|
|
||
| const isExpoMetroConfig = (config: MetroConfig) => { | ||
| const transformerPath = config.transformerPath | ||
| const transformer = config.transformer as ExpoTransformerConfig | undefined | ||
| const hasExpoTransformerField = transformer | ||
| ? '_expoRelativeProjectRoot' in transformer | ||
| || '_expoRouterPath' in transformer | ||
| || 'expo_customTransformerPath' in transformer | ||
| || 'postcssHash' in transformer | ||
| : false | ||
|
|
||
| return Boolean( | ||
| transformerPath?.includes('@expo/metro-config') | ||
| || hasExpoTransformerField, | ||
| ) | ||
| } | ||
|
|
There was a problem hiding this comment.
maybe we could just scan all transformer keys to start with expo or _expo? Having those manually defined doesn't seem easy to maintain, especially because it looks like some expo's internal stuff
| uniwind: bundlerConfig.toMetroConfig(), | ||
| uniwind: { | ||
| ...bundlerConfig.toMetroConfig(), | ||
| isExpoProject: isExpoMetroConfig(config), | ||
| }, |
There was a problem hiding this comment.
extend toMetroConfig method to accept isExpoProject param instead of spreading object there to add new property
| const cssArtifactPath = path.resolve(__dirname, '../../uniwind.css') | ||
|
|
||
| let worker: typeof MetroTransformWorker | ||
| const workerCache = new Map<boolean, typeof MetroTransformWorker>() |
There was a problem hiding this comment.
boolean as a Map key seems random at first glance, please add a small comment there explaining it
2 participants
This fixes monorepos that contain both an Expo app and a plain React Native app, where the plain RN app can accidentally resolve Expo's transform worker and fail to build.
Repro app: https://github.com/sync/uniwee
On main, which has this patch applied,
pnpm build:iossucceeds. On thewithout-patchbranch,pnpm build:iosfails with:Unexpected module with full source map found: node_modules/metro-runtime/src/polyfills/require.js
Summary by CodeRabbit
isExpoProjectsetting to Metro bundling configuration.