Develop #11
Develop #11
Conversation
WalkthroughThis update introduces a comprehensive set of project scaffolding, configuration, and code changes. It adds Android and iOS example app projects, updates and modernizes build, lint, and test tooling, refines TypeScript and Babel configurations, and revises dependencies and scripts. The codebase now uses updated React Native, Expo, and Hugging Face Transformers integrations, with new CI workflows, Git hooks, and resource files for mobile platforms. Changes
Sequence Diagram(s)sequenceDiagram
participant User
participant App (React Native)
participant Pipeline Loader
participant File System
participant ONNX Model
participant Text Generation
User->>App (React Native): Selects model from preset
App (React Native)->>Pipeline Loader: Initialize pipeline with model & ONNX path
Pipeline Loader->>File System: Check if model files exist
alt Files missing
Pipeline Loader->>File System: Download files with progress
File System-->>App (React Native): Progress updates
end
Pipeline Loader-->>App (React Native): Pipeline ready
User->>App (React Native): Enter prompt and request generation
App (React Native)->>Text Generation: Generate text with prompt
Text Generation->>ONNX Model: Run inference
ONNX Model-->>Text Generation: Output tokens
Text Generation-->>App (React Native): Output text
App (React Native)-->>User: Display generated output
Poem
Warning There were issues while running some tools. Please review the errors and either fix the tool's configuration or disable the tool if it's a critical failure. 🔧 ESLint
yarn install v1.22.22 Note ⚡️ AI Code Reviews for VS Code, Cursor, WindsurfCodeRabbit now has a plugin for VS Code, Cursor and Windsurf. This brings AI code reviews directly in the code editor. Each commit is reviewed immediately, finding bugs before the PR is raised. Seamless context handoff to your AI code agent ensures that you can easily incorporate review feedback. ✨ Finishing Touches
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. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 15
🔭 Outside diff range comments (4)
.github/ISSUE_TEMPLATE/bug_report.yml (1)
61-69: 🛠️ Refactor suggestionFix trailing whitespace and incorrect render type
Remove the trailing space in the label and update the
renderproperty tourlfor an input field expecting a link.- - type: input - id: reproducible-example - attributes: - label: Reproducible example repository - description: Please provide a link to a repository on GitHub with a reproducible example. - render: js + - type: input + id: reproducible-example + attributes: + label: Reproducible example repository + description: Please provide a link to a repository on GitHub with a reproducible example. + render: url🧰 Tools
🪛 YAMLlint (1.37.1)
[error] 64-64: trailing spaces
(trailing-spaces)
example/patches/expo-modules-core+2.3.13.patch (1)
1-44: 💡 Verification agent🧩 Analysis chain
Verify patch necessity and update strategy.
This patch modifies a third-party dependency. Consider documenting why this patch is needed and plan for handling future updates of expo-modules-core.
Consider documenting this patch's purpose in a README or comment for future maintainers.
🏁 Script executed:
#!/bin/bash # Check if there are any open issues or discussions about onGeometryChange deprecation echo "Checking for related issues in expo-modules-core repository..." gh search issues --repo expo/expo "onGeometryChange" --state=all gh search issues --repo expo/expo "GeometryReader preference" --state=allLength of output: 5707
🏁 Script executed:
#!/bin/bash echo "🔍 Searching expo/expo for any discussions on deprecations or API changes…" for term in "onGeometryChange" "GeometryReader preference"; do for state in open closed; do echo echo "• Query: \"$term\" (state=$state)" gh search issues --repo expo/expo "$term" --state $state --limit 10 || true done done echo echo "🔎 Scanning local Swift files for any lingering `onGeometryChange` calls…" rg -n "onGeometryChange" --glob "*.swift" || echo "No local references found."Length of output: 1928
Document patch rationale and update plan
This patch replaces the removed
onGeometryChangemodifier in SwiftUI by usingGeometryReader+ a customPreferenceKey. There are currently no related issues or deprecation notices in the upstream expo-modules-core repo, so we’re maintaining this workaround manually until expo-modules-core ships its own fix.Please add:
- A brief header comment at the top of
example/patches/expo-modules-core+2.3.13.patchexplaining:
- Why
onGeometryChangewas replaced- That upstream has no open issue or fix yet
- A new
example/patches/README.mdlisting this patch, its purpose, and the plan to remove it once expo-modules-core ≥ 2.4.0 (or when upstream merges a fix)This will make future upgrades and cleanups straightforward.
example/index.js (1)
1-9: 💡 Verification agent🧩 Analysis chain
Address CI failure: invalid
package.json.Your GitHub Actions log indicates
Web bundling failed due to invalid package.json in dependencies. Please reviewpackage.jsonfor syntax errors or malformed dependency entries (especially underdependencies/devDependencies) to resolve the build error.
🏁 Script executed:
#!/bin/bash set -e # Locate package.json if [ -f package.json ]; then echo "Found package.json at repository root." TARGET="package.json" else echo "Root package.json not found; searching up to 3 levels deep..." TARGET=$(find . -maxdepth 3 -type f -name package.json | head -n1) if [ -z "$TARGET" ]; then echo "🚨 package.json not found in the repository." exit 1 fi echo "Found package.json at $TARGET." fi # Validate JSON syntax echo "Validating JSON syntax of $TARGET..." if jq . "$TARGET" > /dev/null; then echo "✅ $TARGET is valid JSON." else echo "❌ Invalid JSON syntax in $TARGET." exit 2 fiLength of output: 325
🏁 Script executed:
#!/bin/bash set -e # Check for non-string version entries in dependencies echo "🔍 Checking for non-string version entries under dependencies:" jq '.dependencies | with_entries(select(.value|type!="string"))' package.json echo "🔍 Checking for non-string version entries under devDependencies:" jq '.devDependencies | with_entries(select(.value|type!="string"))' package.json echo "📦 Listing all dependencies and their version types:" jq -r '(.dependencies // {}) + (.devDependencies // {}) | to_entries[] | "\(.key): (\(.value|type)) \(.value)"' package.jsonLength of output: 1640
Fix GitHub-shorthand dependency in package.json
The
package.jsonis valid JSON, so the CI bundling error isn’t due to syntax. The issue likely stems from the GitHub-shorthand dependency:• File: package.json
Underdependencies, the entry"@huggingface/transformers": "github:mybigday/transformers.js-rn#merge"may not be supported by your web bundler.
Please replace it with a supported Git URL or a published semver release. For example:
- "@huggingface/transformers": "github:mybigday/transformers.js-rn#merge" + "@huggingface/transformers": "git+https://github.com/mybigday/transformers.js-rn.git#merge"Or, if possible, install a released version from npm:
"@huggingface/transformers": "1.2.3"After updating, rerun CI to confirm the bundler can resolve this dependency.
🧰 Tools
🪛 GitHub Actions: CI
[error] 1-1: Web bundling failed due to invalid package.json in dependencies, causing build process to exit with code 1.
src/index.tsx (1)
1-13: 💡 Verification agent🧩 Analysis chain
Clean removal of embedding functionality, but verify test cleanup.
The code correctly removes all embedding-related exports and maintains only text generation functionality. However, ensure that corresponding test files for embedding functionality are also removed to maintain consistency.
Please verify that all embedding-related test files and unused code are also removed:
🏁 Script executed:
#!/bin/bash # Check for remaining embedding-related files that should be cleaned up echo "Searching for embedding-related test files:" fd "embedding" --type f echo -e "\nSearching for embedding references in source code:" rg -n "embedding" --type typescript --type tsx src/ echo -e "\nChecking for unused imports or models:" fd "text-embedding" --type f src/Length of output: 759
Remove remaining embedding-related tests and code
The repository still contains embedding-related implementation and test files that should be removed to fully clean up embedding functionality:
- src/models/text-embedding.tsx
- src/pipelines/text-embedding.tsx
- src/tests/text-embedding.model.test.tsx
- src/tests/text-embedding.pipeline.test.tsx
Please delete or refactor these files so that the codebase no longer references embedding.
🧹 Nitpick comments (22)
.github/ISSUE_TEMPLATE/bug_report.yml (1)
14-24: Capitalize "React Native" in checklist labelsProduct names should use proper casing. Change "react native" to "React Native" in the second checkbox option.
- - label: I tested using a [supported version](https://github.com/reactwg/react-native-releases/blob/main/docs/support.md) of react native. + - label: I tested using a [supported version](https://github.com/reactwg/react-native-releases/blob/main/docs/support.md) of React Native.src/__tests__/index.test.tsx (1)
1-1: Replace placeholder test with real assertions
Theit.todoline is a placeholder. Consider implementing actual test cases to validate your component or module functionality.Would you like me to draft a starter test for this file?
example/android/app/src/main/res/values/colors.xml (1)
1-6: Consider adding night mode color support.Since there's a
values-nightdirectory with an empty colors.xml file, consider defining appropriate dark theme colors for better user experience in night mode.Would you like me to suggest appropriate night mode color values for these resources?
example/ios/example/example-Bridging-Header.h (1)
1-4: Initialize or remove empty bridging header
This bridging header is currently just a placeholder. If you plan to expose Objective-C headers to Swift, import them here (e.g., React headers). Otherwise, consider removing this file until it's needed to reduce maintenance overhead.example/android/.gitignore (1)
1-16: Consider enhancing ignore patterns for Gradle wrappers and module builds.The current
.gitignorecovers the top-levelbuild/, IDE files, and some artifacts, but Android projects often have build directories in module subfolders (e.g.,app/build/) and the Gradle wrapper scripts.Proposed additions:
+ **/build/ + gradlew + gradlew.bat + gradle/wrapper/example/src/presets.json (1)
1-28: Add schema or type definitions for presets.Consider defining a JSON Schema or corresponding TypeScript interface for
presets.jsonto enforce the expected structure at build time and catch malformed entries early.example/android/app/src/main/res/values/styles.xml (1)
2-6: Avoid hard-coded color values.Instead of using the literal
#ffffffforandroid:statusBarColor, reference a color resource (e.g.,@color/whiteor@color/colorOnPrimary) defined incolors.xmlto maintain theming consistency.jest.config.js (1)
16-16: Consider simplifying the test regex pattern.The current test regex uses a negative lookbehind
(?<!setup)which might be unnecessarily complex. Consider using a simpler exclude pattern in Jest'stestPathIgnorePatternsif the goal is to exclude setup files.Alternative approach using
testPathIgnorePatterns:testRegex: '(/__tests__/.*(?<!setup)\\.(test|spec))\\.[jt]sx?$', + testPathIgnorePatterns: ['/__tests__/setup\\.js$'],Or simplify to a standard pattern:
- testRegex: '(/__tests__/.*(?<!setup)\\.(test|spec))\\.[jt]sx?$', + testRegex: '(/__tests__/.*\\.(test|spec))\\.[jt]sx?$',example/android/app/src/main/res/values/strings.xml (1)
2-2: Consider a more descriptive app name for the example.While "example" is functional, consider using a more descriptive name like "TransformersExample" or "HFTransformersDemo" to better reflect the purpose of the example app.
- <string name="app_name">example</string> + <string name="app_name">Transformers Example</string>README.md (1)
75-76: Babel plugin addition is appropriate.Including
'babel-plugin-transform-import-meta'ensures import.meta compatibility. Confirm that plugin order aligns with other transforms.Consider adding a brief comment on why this plugin is needed.
example/src/App.tsx (2)
87-87: Improve progress display formatting.The progress is displayed as a raw decimal number which is not user-friendly. Consider formatting it as a percentage.
- <Text>{progress}</Text> + <Text>{progress ? `Download Progress: ${(progress * 100).toFixed(1)}%` : ''}</Text>
74-83: Missing loading state for model loading.The UI doesn't provide feedback when a model is being loaded, which could confuse users especially for large models.
Add a loading state and disable buttons during model loading:
const [progress, setProgress] = React.useState<number>(); const [input, setInput] = React.useState<string>('We love local LLM'); const [output, setOutput] = React.useState<string>(); + const [isLoading, setIsLoading] = React.useState<boolean>(false); const loadModel = async (preset: { // ... existing code }) => { + setIsLoading(true); console.log('loading'); await Pipeline.TextGeneration.init(preset.model, preset.onnx_path, { // ... existing code }); console.log('loaded'); + setIsLoading(false); }; // In render: <Button key={preset.name} title={preset.name} + disabled={isLoading} onPress={() => { loadModel(preset); }} />src/__tests__/setup.js (1)
17-21: UseTextEncoderfor arrayBuffer mocks
Chaining.split('').map(...).bufferworks but can be simplified and made more robust via the Web API:- Promise.resolve( - Uint8Array.from( - JSON.stringify({ /* config */ }) - .split('') - .map(c => c.charCodeAt(0)) - ).buffer - ) + Promise.resolve( + (new TextEncoder().encode(JSON.stringify({ /* config */ }))).buffer + )This avoids manual string-to-bytes transformation.
example/android/settings.gradle (1)
2-8: Consider adding error handling for dynamic path resolution.The dynamic path resolution using Node.js commands is a common pattern, but it lacks error handling. If the
nodecommand fails or the required packages aren't installed, the build will fail with unclear error messages.Consider adding error handling or fallback mechanisms for more robust builds.
example/ios/example/SplashScreen.storyboard (1)
24-29: Consider using safe area constraints for better device compatibility.The current constraints pin the image view to the container view's edges. Consider using safe area constraints to ensure proper display on devices with notches or dynamic islands.
- <constraint firstItem="EXPO-SplashScreen" firstAttribute="top" secondItem="EXPO-ContainerView" secondAttribute="top" id="83fcb9b545b870ba44c24f0feeb116490c499c52"/> + <constraint firstItem="EXPO-SplashScreen" firstAttribute="top" secondItem="Rmq-lb-GrQ" secondAttribute="top" id="83fcb9b545b870ba44c24f0feeb116490c499c52"/>example/ios/example.xcodeproj/xcshareddata/xcschemes/example.xcscheme (1)
3-3: Consider updating the Xcode version.The
LastUpgradeVersion = "1130"corresponds to Xcode 11.3, which is quite outdated. Consider updating this to a more recent Xcode version to ensure compatibility with modern iOS development tools and features.- LastUpgradeVersion = "1130" + LastUpgradeVersion = "1500".github/actions/setup/action.yml (1)
20-22: Consider adding more granular restore keys.The restore keys provide good fallback options, but you might want to consider adding a restore key that includes Node.js version for better cache efficiency across different Node.js versions.
restore-keys: | + ${{ runner.os }}-yarn-${{ hashFiles('yarn.lock') }}-node-${{ hashFiles('.nvmrc') }} ${{ runner.os }}-yarn-${{ hashFiles('yarn.lock') }} ${{ runner.os }}-yarn-example/ios/Podfile (1)
1-64: Well-configured Podfile with modern React Native + Expo setup!The Podfile demonstrates excellent practices:
- Dynamic configuration from properties file
- Proper Expo modules integration
- Conditional autolinking based on environment
- Xcode 14 compatibility fixes in post-install hook
- Flexible framework linkage configuration
Address RuboCop style issues for consistency:
-podfile_properties = JSON.parse(File.read(File.join(__dir__, 'Podfile.properties.json'))) rescue {} +begin + podfile_properties = JSON.parse(File.read(File.join(__dir__, 'Podfile.properties.json'))) +rescue + podfile_properties = {} +end'ios' - ] + ],:app_path => "#{Pod::Config.instance.installation_root}/..", - :privacy_file_aggregation_enabled => podfile_properties['apple.privacyManifestAggregationEnabled'] != 'false', + :privacy_file_aggregation_enabled => podfile_properties['apple.privacyManifestAggregationEnabled'] != 'false':mac_catalyst_enabled => false, - :ccache_enabled => podfile_properties['apple.ccacheEnabled'] == 'true', + :ccache_enabled => podfile_properties['apple.ccacheEnabled'] == 'true'🧰 Tools
🪛 RuboCop (1.75.5)
[convention] 5-5: Avoid using
rescuein its modifier form.(Style/RescueModifier)
[convention] 28-28: Put a comma after the last item of a multiline array.
(Style/TrailingCommaInArrayLiteral)
[convention] 42-42: Avoid comma after the last parameter of a method call.
(Style/TrailingCommaInArguments)
[convention] 50-50: Avoid comma after the last parameter of a method call.
(Style/TrailingCommaInArguments)
package.json (4)
9-13: Good: Modernexportsfield usage.The
exportsmap cleanly declares entry points for source, types, and default consumers.
Consider adding any platform-specific exports (e.g., a"react-native"entry) if needed for packagers.
36-43: Consider exposing abuildscript.You rely on the
preparehook (bob build) for package builds, but it can be helpful to have an explicit"build": "bob build"entry for manual invocation and CI clarity.
79-84: DevDependencies: Core libraries and build tools.Pinning
prettier,react,react-native,react-native-builder-bob,release-it, andtypescriptensures consistency.
Consider tightening your peer ranges in tandem with these versions.
86-89: Restrict peerDependencies version ranges.Using
"*"allows any React/React Native version and may introduce breaking changes. It’s safer to target tested ranges, for example:"peerDependencies": { "react": ">=18 <21", "react-native": ">=0.70 <1.0" }
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (13)
example/android/app/src/main/res/drawable-hdpi/splashscreen_logo.pngis excluded by!**/*.pngexample/android/app/src/main/res/drawable-mdpi/splashscreen_logo.pngis excluded by!**/*.pngexample/android/app/src/main/res/drawable-xhdpi/splashscreen_logo.pngis excluded by!**/*.pngexample/android/app/src/main/res/drawable-xxhdpi/splashscreen_logo.pngis excluded by!**/*.pngexample/android/app/src/main/res/drawable-xxxhdpi/splashscreen_logo.pngis excluded by!**/*.pngexample/android/gradle/wrapper/gradle-wrapper.jaris excluded by!**/*.jarexample/assets/splash-icon.pngis excluded by!**/*.pngexample/ios/Podfile.lockis excluded by!**/*.lockexample/ios/example/Images.xcassets/AppIcon.appiconset/App-Icon-1024x1024@1x.pngis excluded by!**/*.pngexample/ios/example/Images.xcassets/SplashScreenLogo.imageset/image.pngis excluded by!**/*.pngexample/ios/example/Images.xcassets/SplashScreenLogo.imageset/image@2x.pngis excluded by!**/*.pngexample/ios/example/Images.xcassets/SplashScreenLogo.imageset/image@3x.pngis excluded by!**/*.pngyarn.lockis excluded by!**/yarn.lock,!**/*.lock
📒 Files selected for processing (73)
.github/ISSUE_TEMPLATE/bug_report.yml(1 hunks).github/ISSUE_TEMPLATE/config.yml(1 hunks).github/actions/setup/action.yml(1 hunks).github/workflows/ci.yml(1 hunks).gitignore(2 hunks).nvmrc(1 hunks).watchmanconfig(1 hunks)CONTRIBUTING.md(1 hunks)LICENSE(1 hunks)README.md(8 hunks)babel.config.js(1 hunks)eslint.config.mjs(1 hunks)example/android/.gitignore(1 hunks)example/android/app/build.gradle(1 hunks)example/android/app/proguard-rules.pro(1 hunks)example/android/app/src/debug/AndroidManifest.xml(1 hunks)example/android/app/src/main/AndroidManifest.xml(1 hunks)example/android/app/src/main/java/transformers/example/MainActivity.kt(1 hunks)example/android/app/src/main/java/transformers/example/MainApplication.kt(1 hunks)example/android/app/src/main/res/drawable/ic_launcher_background.xml(1 hunks)example/android/app/src/main/res/drawable/rn_edit_text_material.xml(1 hunks)example/android/app/src/main/res/mipmap-anydpi-v26/ic_launcher.xml(1 hunks)example/android/app/src/main/res/mipmap-anydpi-v26/ic_launcher_round.xml(1 hunks)example/android/app/src/main/res/values-night/colors.xml(1 hunks)example/android/app/src/main/res/values/colors.xml(1 hunks)example/android/app/src/main/res/values/strings.xml(1 hunks)example/android/app/src/main/res/values/styles.xml(1 hunks)example/android/build.gradle(1 hunks)example/android/gradle.properties(1 hunks)example/android/gradle/wrapper/gradle-wrapper.properties(1 hunks)example/android/gradlew(1 hunks)example/android/gradlew.bat(1 hunks)example/android/settings.gradle(1 hunks)example/app.json(2 hunks)example/babel.config.js(1 hunks)example/index.js(1 hunks)example/ios/.gitignore(1 hunks)example/ios/.xcode.env(1 hunks)example/ios/Podfile(1 hunks)example/ios/Podfile.properties.json(1 hunks)example/ios/example.xcodeproj/project.pbxproj(1 hunks)example/ios/example.xcodeproj/xcshareddata/xcschemes/example.xcscheme(1 hunks)example/ios/example.xcworkspace/contents.xcworkspacedata(1 hunks)example/ios/example/AppDelegate.swift(1 hunks)example/ios/example/Images.xcassets/AppIcon.appiconset/Contents.json(1 hunks)example/ios/example/Images.xcassets/Contents.json(1 hunks)example/ios/example/Images.xcassets/SplashScreenBackground.colorset/Contents.json(1 hunks)example/ios/example/Images.xcassets/SplashScreenLogo.imageset/Contents.json(1 hunks)example/ios/example/Info.plist(1 hunks)example/ios/example/PrivacyInfo.xcprivacy(1 hunks)example/ios/example/SplashScreen.storyboard(1 hunks)example/ios/example/Supporting/Expo.plist(1 hunks)example/ios/example/example-Bridging-Header.h(1 hunks)example/ios/example/example.entitlements(1 hunks)example/metro.config.js(1 hunks)example/package.json(1 hunks)example/patches/expo-modules-core+2.3.13.patch(1 hunks)example/src/App.tsx(1 hunks)example/src/presets.json(1 hunks)example/tsconfig.json(1 hunks)jest.config.js(1 hunks)lefthook.yml(1 hunks)package.json(2 hunks)patches/native-universal-fs+0.2.0.patch(1 hunks)src/__tests__/index.test.tsx(1 hunks)src/__tests__/setup.js(2 hunks)src/__tests__/text-embedding.pipeline.test.tsx(2 hunks)src/__tests__/text-generation.pipeline.test.tsx(2 hunks)src/index.tsx(1 hunks)src/pipelines/text-embedding.tsx(5 hunks)src/pipelines/text-generation.tsx(8 hunks)tsconfig.build.json(1 hunks)tsconfig.json(1 hunks)
🧰 Additional context used
🧬 Code Graph Analysis (2)
example/index.js (1)
example/src/App.tsx (1)
App(13-91)
example/src/App.tsx (2)
example/App.tsx (1)
App(13-90)src/index.tsx (1)
Pipeline(4-4)
🪛 GitHub Actions: CI
example/index.js
[error] 1-1: Web bundling failed due to invalid package.json in dependencies, causing build process to exit with code 1.
src/pipelines/text-generation.tsx
[error] 5-5: Cannot find module '@huggingface/transformers' or its corresponding type declarations. (TS2307)
[error] 7-7: 'LoadOptions' is a type and must be imported using a type-only import when 'verbatimModuleSyntax' is enabled. (TS1484)
src/__tests__/text-generation.pipeline.test.tsx
[error] 2-2: Cannot find module '@huggingface/transformers' or its corresponding type declarations. (TS2307)
src/pipelines/text-embedding.tsx
[error] 5-5: Cannot find module '@huggingface/transformers' or its corresponding type declarations. (TS2307)
[error] 7-7: 'LoadOptions' is a type and must be imported using a type-only import when 'verbatimModuleSyntax' is enabled. (TS1484)
package.json
[warning] 1-1: Invalid package.json configuration: 'exports' resolution points to a non-existent file 'dist/transformers.web.js'.
[error] 1-1: Invalid package.json 'main' module field: specified path 'dist/module/index' could not be resolved; none of the expected files exist.
🪛 YAMLlint (1.37.1)
.github/ISSUE_TEMPLATE/bug_report.yml
[error] 64-64: trailing spaces
(trailing-spaces)
🪛 RuboCop (1.75.5)
example/ios/Podfile
[convention] 5-5: Avoid using rescue in its modifier form.
(Style/RescueModifier)
[convention] 28-28: Put a comma after the last item of a multiline array.
(Style/TrailingCommaInArrayLiteral)
[convention] 42-42: Avoid comma after the last parameter of a method call.
(Style/TrailingCommaInArguments)
[convention] 50-50: Avoid comma after the last parameter of a method call.
(Style/TrailingCommaInArguments)
🔇 Additional comments (106)
.github/ISSUE_TEMPLATE/config.yml (1)
1-8: Configuration for issue templates is correctThe
blank_issues_enabledflag is properly disabled, and the contact links are clearly defined for feature requests and general discussions..github/ISSUE_TEMPLATE/bug_report.yml (1)
1-3: Metadata fields look goodName, description, and labels are appropriately defined for the bug report template.
patches/native-universal-fs+0.2.0.patch (1)
25-27:❓ Verification inconclusive
Verify expo-file-system availability and error handling.
With the removal of fallback filesystem libraries, the code now has a hard dependency on
expo-file-system. Ensure proper error handling exists if this module is unavailable.
🏁 Script executed:
#!/bin/bash # Description: Verify expo-file-system is properly configured and available # Expected: Should find expo-file-system in dependencies and proper error handling echo "Checking if expo-file-system is in dependencies:" fd "package\.json" --exec grep -l "expo-file-system" {} echo -e "\nVerifying expo-file-system imports across the codebase:" rg "expo-file-system" --type js --type ts echo -e "\nChecking for error handling around expo-file-system usage:" rg -A 5 -B 5 "require.*expo-file-system" --type js --type tsLength of output: 684
I want to inspect the patch to confirm the presence of the
catchblock and full context around therequire("expo-file-system").LICENSE (1)
3-3: License year update aligned with release
The copyright year has been updated to 2025..watchmanconfig (1)
1-1: Approve addition of empty Watchman configuration
An empty.watchmanconfigfile is a common default to ensure consistent Watchman behavior.example/ios/example/example.entitlements (1)
1-5:✅ Verification successful
Confirm entitlements file is integrated into the Xcode project
Please verify thatexample.entitlementsis referenced inexample.xcodeprojso iOS builds include it.Run this script from the repo root to verify:
🏁 Script executed:
#!/bin/bash # Verify entitlements file reference in the Xcode project if grep -R "example.entitlements" -n example/ios/example.xcodeproj/project.pbxproj; then echo "✅ Entitlements file is referenced in the Xcode project." else echo "❌ Entitlements file is not referenced. Please ensure it's added to the Xcode project." exit 1 fiLength of output: 326
Entitlements file reference confirmed
Verified thatexample.entitlementsis referenced inexample.xcodeproj(lines 333 and 369), so iOS builds will include it.example/ios/Podfile.properties.json (1)
1-5:✅ Verification successful
Ensure Podfile properties JSON is consumed by Podfile
Verify thatPodfile.properties.jsonis loaded in yourPodfileso thatexpo.jsEngine,EX_DEV_CLIENT_NETWORK_INSPECTOR, andnewArchEnabledsettings take effect.
🏁 Script executed:
#!/bin/bash # Check for Podfile reference to Podfile.properties.json if grep -R "Podfile.properties.json" -n example/ios/Podfile; then echo "✅ Podfile.properties.json is referenced in Podfile." else echo "❌ Podfile.properties.json is not referenced. Please update your Podfile to load it." exit 1 fiLength of output: 271
Podfile.properties.json successfully loaded in Podfile
ThePodfileincludes a reference toPodfile.properties.json(line 5), so yourexpo.jsEngine,EX_DEV_CLIENT_NETWORK_INSPECTOR, andnewArchEnabledsettings will be applied as expected. No further action needed.example/android/gradle/wrapper/gradle-wrapper.properties (2)
1-7: LGTM - Standard Gradle wrapper configuration.The Gradle wrapper configuration follows standard conventions with appropriate timeout settings and validation enabled.
3-3:✅ Verification successful
Verify Gradle version currency and security.
Ensure that Gradle 8.13 is a current and secure version without known vulnerabilities.
🌐 Web query:
What is the latest stable version of Gradle and are there any known security vulnerabilities in Gradle 8.13?💡 Result:
Latest Stable Version of Gradle
The latest stable version of Gradle as of May 24, 2025 is Gradle 8.14.1, released on May 22, 20251.
Security Vulnerabilities in Gradle 8.13
Gradle 8.13 specifically addressed a recent high-severity security vulnerability tracked as CVE-2025-27148. This vulnerability allowed local attackers on Unix-like systems to potentially escalate privileges due to insecure handling of the system temporary directory[6][9]. The vulnerability was present in prior versions (notably 8.12), but was patched in Gradle 8.12.1 and all subsequent releases, including 8.13[6][9]. The fix involved upgrading the native-platform library to a version that addresses the temporary directory handling issue[9].
Summary table:
Version Release Date CVE-2025-27148 Vulnerability Status 8.12 Early 2025 Vulnerable 8.12.1 Feb 2025 Patched (fixed) 8.13 Feb/Mar 2025 Patched (fixed) 8.14.1 May 22, 2025 Patched (fixed, latest stable) There are currently no widely reported unpatched security vulnerabilities specific to Gradle 8.13. If you are using 8.13 or later, you are protected against CVE-2025-27148 and do not need to apply additional mitigations beyond regular updates[6][9].
In summary:
- The latest stable Gradle release is 8.14.11.
- Gradle 8.13 is not vulnerable to CVE-2025-27148 or other widely reported recent vulnerabilities. Systems using 8.13 are considered secure against this privilege escalation issue[6][9].
Citations:
- 1: https://gradle.org/releases/
- 2: https://docs.gradle.org/8.14/release-notes.html
- 3: https://developer.android.com/build/releases/gradle-plugin
- 4: https://github.com/gradle/gradle/releases
- 5: https://gradle.org/whats-new/gradle-9/
- 6: https://securityonline.info/gradle-build-automation-tool-vulnerable-to-privilege-escalation-cve-2025-27148/
- 7: https://developer.android.com/build/releases/past-releases/agp-8-4-0-release-notes
- 8: https://developer.android.com/build/releases/past-releases/agp-8-8-0-release-notes
- 9: https://feedly.com/cve/CVE-2025-27148
- 10: https://feedly.com/cve/vendors/gradle
Gradle 8.13 Is Secure and Patched
Gradle 8.13 includes the fix for CVE-2025-27148 (introduced in 8.12) and has no known unpatched vulnerabilities. The current latest stable release is Gradle 8.14.1 (May 22, 2025); upgrading is optional for feature updates but not required for security.• example/android/gradle/wrapper/gradle-wrapper.properties:
distributionUrl=https\://services.gradle.org/distributions/gradle-8.13-bin.zipremains a secure choice.example/patches/expo-modules-core+2.3.13.patch (2)
9-14: LGTM - Well-implemented PreferenceKey.The
SizePreferenceKeyimplementation correctly follows SwiftUI's PreferenceKey protocol with appropriate default value and reduce function.
29-40: LGTM - Proper preference-based geometry tracking.The replacement of
onGeometryChangewith the preference-based approach usingGeometryReaderandonPreferenceChangeis well-implemented and follows SwiftUI best practices. The size calculation logic is preserved correctly.Could you clarify why this patch was necessary? Was
onGeometryChangedeprecated or causing compatibility issues?tsconfig.json (3)
3-3: EnsurerootDiris correctly scoped
ChangingrootDirto.can unintentionally include files outsidesrc/. Consider adding explicitinclude/excludesettings to prevent type-checking of non-source directories (e.g.,node_modules, build artifacts).
4-6: Validate path alias mapping
The new alias"react-native-transformers"points to./src/index. Please confirm thatsrc/index.(ts|tsx)exists and that this alias is documented in your module resolution strategy.
7-27: Adopted strict compiler settings
The explicit strict options (e.g.,noUnusedLocals,noImplicitReturns,noUncheckedIndexedAccess) and modern ESNext targets align well with our goals for type safety and future-proofing..nvmrc (1)
1-1: Pin Node.js version via.nvmrc
Locking tov20.19.0ensures consistency across environments. Consider adding anenginesfield inpackage.jsonto enforce this version in CI/CD and on install.
[approve_code_changes, suggest_optional_refactor]tsconfig.build.json (1)
1-4: Dedicated build config extends base settings
Extending./tsconfigand excludingexampleandlibdirectories properly scopes the build. Optionally, you could add an explicitincludearray (e.g.,"src/**/*") to further clarify source files targeted by the build.
[approve_code_changes, suggest_optional_refactor]example/ios/example/Images.xcassets/Contents.json (1)
1-6: Add asset catalog metadata
ThisContents.jsoncorrectly initializes the asset catalog withversion: 1andauthor: "expo". Everything looks good for the new iOS example project setup.CONTRIBUTING.md (1)
46-53: Confirmation step is clear and helpful.The added instructions to check the Metro logs for
"fabric":trueand"concurrentRoot":trueprovide a straightforward verification of the new architecture in the example app.example/ios/example.xcworkspace/contents.xcworkspacedata (1)
1-10: Workspace configuration is correctly defined.The new Xcode workspace file properly groups the main app project and the CocoaPods project, facilitating development in Xcode with native dependencies.
example/android/app/src/main/res/mipmap-anydpi-v26/ic_launcher_round.xml (1)
1-5: Adaptive icon resource is defined correctly.The XML for the round adaptive launcher icon correctly references the background and foreground layers as per Android adaptive icon guidelines.
example/tsconfig.json (1)
1-6: Minimal tsconfig override is appropriate.Extending the root-level
tsconfigand including a comment to prevent Expo CLI from auto-generating a tsconfig file aligns with the new centralized configuration approach.example/android/app/src/main/res/drawable/ic_launcher_background.xml (1)
1-6: Launcher background drawable is correct.The
<layer-list>correctly defines the splash screen background color and centers the logo bitmap, matching the intended design.example/android/app/proguard-rules.pro (1)
10-12: Ensure ProGuard rules are properly applied in Gradle configuration.The
-keepdirectives forreanimatedandturbomodulelook correct. Verify thatproguard-rules.prois referenced in yourapp/build.gradle(typically viaproguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro') and thatminifyEnabledis enabled for release builds.example/android/app/src/main/res/mipmap-anydpi-v26/ic_launcher.xml (1)
3-4: Validate referenced drawables exist.The adaptive icon references
@color/iconBackgroundand@mipmap/ic_launcher_foreground. Confirm that these resources exist and are correctly named in yourres/colorandres/mipmapdirectories to prevent runtime crashes.example/index.js (1)
1-9: Root component registration is correct.
registerRootComponent(App)properly initializes the app for both Expo Go and native builds.🧰 Tools
🪛 GitHub Actions: CI
[error] 1-1: Web bundling failed due to invalid package.json in dependencies, causing build process to exit with code 1.
example/ios/example/Images.xcassets/AppIcon.appiconset/Contents.json (1)
4-8: Confirm app icon asset filename and catalog consistency.The JSON specifies
"filename": "App-Icon-1024x1024@1x.png". Ensure this file exists at the same path and that the asset catalog contains the corresponding image. Mismatches here can lead to missing app icons in the build.example/ios/example/Supporting/Expo.plist (1)
5-10: Confirm Expo updates configuration for iOS example app.You’ve disabled updates (
EXUpdatesEnabled = false) while still checking on launch (EXUpdatesCheckOnLaunch = "ALWAYS") with zero wait time. Please confirm this aligns with your intended behavior for the example app and matches the Android metadata settings.example/ios/example/Images.xcassets/SplashScreenLogo.imageset/Contents.json (1)
1-23: Validate asset filenames.Ensure that
image.png,image@2x.png, andimage@3x.pngactually exist in this imageset folder and match the names referenced here. Any mismatch will cause the splash screen build to fail.example/src/presets.json (1)
1-28: Validate ONNX model file paths.Confirm that the referenced ONNX files (e.g.,
onnx/model_q4.onnx,onnx/decoder_model_merged.onnx) are present in your bundle at runtime and that these paths align with your Metro bundler or asset setup.example/android/app/src/main/res/values/styles.xml (1)
2-3: Verify parent theme availability.Please ensure that
Theme.EdgeToEdgeis provided by your project’s dependencies (e.g., Material Components) and is compatible with your minimum SDK level to prevent runtime inflation errors.example/android/app/src/debug/AndroidManifest.xml (2)
4-4: Verify the necessity of SYSTEM_ALERT_WINDOW permission.The
SYSTEM_ALERT_WINDOWpermission allows the app to create overlay windows that appear on top of other apps. This is a dangerous permission that requires user consent on Android 6.0+ and should only be used if absolutely necessary for debugging purposes.Please confirm this permission is required for your debugging workflow, as it could pose security risks if misused.
6-6: Cleartext traffic configuration is appropriate for debug builds.The
usesCleartextTraffic="true"setting allows HTTP traffic, which is useful for debugging but should never be enabled in production builds. Since this is in the debug manifest, this configuration is appropriate.example/ios/example/Images.xcassets/SplashScreenBackground.colorset/Contents.json (1)
1-20: LGTM! Standard iOS color asset definition.The color asset definition follows Apple's standard format correctly. The pure white color (RGB: 1.0, 1.0, 1.0) is properly defined with universal idiom for consistent splash screen theming across all iOS devices.
example/ios/.gitignore (1)
1-31: Comprehensive iOS .gitignore following best practices.The .gitignore file correctly excludes:
- macOS system files (.DS_Store)
- Xcode user-specific files and build artifacts
- CocoaPods dependencies (properly excluded since they're installed via
pod install)- React Native bundle artifacts
This follows iOS development best practices and will prevent unnecessary files from being committed.
example/babel.config.js (1)
1-16:✅ Verification successful
Modernized Babel configuration using react-native-builder-bob.
The refactor to use
react-native-builder-bob'sgetConfigis a good modernization that provides more intelligent configuration based on project metadata and structure.Please verify that the removed
babel-plugin-transform-import-metafunctionality is still working correctly, as it may now be handled automatically by the builder-bob configuration:
🏁 Script executed:
#!/bin/bash # Description: Verify if import.meta usage is properly transformed # Search for import.meta usage in the codebase rg "import\.meta" --type js --type ts --type tsx --type jsx -A 2Length of output: 94
🏁 Script executed:
#!/bin/bash # Re-verify import.meta usage across the entire codebase without file-type restrictions rg "import\\.meta" -A 2Length of output: 205
transform-import-meta removal is safe
Import.meta is only used in
eslint.config.mjs(an ESM file, where Node natively supportsimport.meta.url). There are noimport.metaoccurrences in your source or bundled code, so removing the plugin has no impact.• Location checked:
eslint.config.mjs
• No other matches found in JS/TS/JSX/TSX filesjest.config.js (1)
8-8:✅ Verification successful
Verify the package migration is complete across the codebase.
The migration from
@xenova/transformersto@huggingface/transformersin the transform ignore patterns looks correct.Ensure all references to the old package have been updated consistently:
🏁 Script executed:
#!/bin/bash # Description: Check for any remaining references to the old package name # Expected: No occurrences of @xenova/transformers should remain echo "Checking for remaining @xenova/transformers references..." rg "@xenova/transformers" --type js --type ts --type jsx --type tsx --type json echo "Verifying @huggingface/transformers is used consistently..." rg "@huggingface/transformers" --type js --type ts --type jsx --type tsx --type jsonLength of output: 474
🏁 Script executed:
#!/bin/bash # Retry searching with proper glob patterns to include JSX/TSX files echo "Re-checking for remaining @xenova/transformers references..." rg "@xenova/transformers" --glob "*.{js,ts,jsx,tsx,json}" echo "Verifying @huggingface/transformers is used consistently..." rg "@huggingface/transformers" --glob "*.{js,ts,jsx,tsx,json}"Length of output: 1286
✅ Migration Verified: No Remaining @xenova/transformers References
All checks confirm that the old package name has been fully replaced and the new import is used consistently:
• No occurrences of
@xenova/transformersfound
•@huggingface/transformersappears in:
- package.json
- jest.config.js
- src/pipelines/text-generation.tsx
- src/pipelines/text-embedding.tsx
- src/tests/text-generation.pipeline.test.tsx
- src/tests/text-embedding.pipeline.test.tsx
- src/tests/setup.js
No further action required.
example/android/app/src/main/res/values/strings.xml (1)
1-5: Well-structured Android string resources.The XML structure follows Android best practices with proper use of
translatable="false"for configuration values that shouldn't be localized.example/ios/.xcode.env (1)
1-12: Excellent Xcode environment configuration.This file follows React Native and Expo best practices for iOS development:
- Uses
command -v nodewhich is more reliable than hardcoded paths- Includes clear documentation for customization
- Properly versioned while allowing local overrides via
.xcode.env.localThe configuration aligns well with the
.gitignoreupdate that excludes local environment files..gitignore (3)
31-31: Good addition of iOS environment file exclusion.The pattern
**/.xcode.env.localcorrectly excludes local Xcode environment files from version control while allowing the base.xcode.envfile to be tracked.
78-79: Clear documentation for generated lib directory.The updated comment clarifies that the
lib/directory is generated by "bob" (react-native-builder-bob), which helps developers understand the purpose of this ignore pattern.
81-86: Appropriate patterns for modern React Native development.These additions properly exclude generated code directories:
ios/generatedandandroid/generatedfor React Native Codegen outputnitrogen/for React Native Nitro ModulesThese patterns align with current React Native best practices and the new architecture.
example/metro.config.js (2)
1-21: Well-structured Metro configuration for monorepo setup.The configuration follows best practices:
- Proper use of Expo's default config as base
- Monorepo support via
react-native-monorepo-config- Good JSDoc typing for better IDE support
- Clear root directory resolution
18-18:❓ Verification inconclusive
Monitor the experimental package exports feature.
The
unstable_enablePackageExportsoption is marked as unstable. While this enables modern package.json exports support, monitor for any build issues and be prepared to disable if problems arise.Consider testing the build process to ensure this experimental feature doesn't cause issues:
🏁 Script executed:
#!/bin/bash # Description: Test Metro bundling with the new configuration # Expected: Successful bundle creation without errors cd example echo "Testing Metro bundle creation..." npx react-native bundle --platform android --dev false --entry-file index.js --bundle-output test-bundle.js --assets-dest test-assets/ || echo "Bundle failed" # Clean up test files rm -f test-bundle.js rm -rf test-assets/Length of output: 1005
Monitor and test the experimental package exports feature
We tried bundling the example app with
unstable_enablePackageExports = true, but the CLI failed due to a missing dependency. To get a meaningful result:
- Add
@react-native-community/clitoexample/package.jsonunderdevDependencies.- Re-run the bundling command:
cd example npx react-native bundle \ --platform android \ --dev false \ --entry-file index.js \ --bundle-output test-bundle.js \ --assets-dest test-assets/- Ensure the bundle completes without errors and that the generated
test-bundle.jsandtest-assets/look correct.- If any build issues arise with
unstable_enablePackageExports, disable this flag until upstream support stabilizes.example/app.json (3)
24-24: ApproveedgeToEdgeEnabledaddition.Enabling edge-to-edge UI on Android improves immersion and aligns with the updated Android theme. Ensure your styles.xml uses windowEdgeToEdge attributes accordingly.
11-11:✅ Verification successful
Confirm the splash image path exists.
The splash screen now points to
./assets/splash-icon.png. Please validate that the file is present in theexample/assetsdirectory to avoid runtime asset resolution errors.
🏁 Script executed:
#!/bin/bash # Check for splash-icon.png in assets fd --exact-name splash-icon.png example/assetsLength of output: 260
#!/bin/bash # Verify splash-icon.png exists in the example/assets directory find example/assets -type f -name splash-icon.png
🏁 Script executed:
#!/bin/bash # Check if splash-icon.png exists in example/assets find example/assets -type f -maxdepth 1 -name "splash-icon.png" -printLength of output: 101
Splash image path verified
The file
example/assets/splash-icon.pngexists, so the"image": "./assets/splash-icon.png"reference is correct. No further changes needed.
9-9:❓ Verification inconclusive
Verify the
newArchEnabledflag compatibility.Enabling the new React Native architecture requires an SDK that supports Fabric and TurboModules. Please ensure your Expo SDK and React Native versions are compatible with
newArchEnabled: true.Run this script to check your Expo SDK version in
package.jsonand confirm it’s ≥ 46:
🏁 Script executed:
#!/bin/bash # Verify Expo SDK version is compatible with new architecture grep -E '"expo":' package.json -A2 | grep sdkVersionLength of output: 54
🏁 Script executed:
#!/bin/bash # Locate Expo dependency version in package.json grep -R '"expo"' -n package.json # Locate sdkVersion in app.json (including the example folder) grep -R '"sdkVersion"' -n .Length of output: 64
Confirm Expo SDK and React Native compatibility for
newArchEnabledOur automated search didn’t find an
sdkVersionin anyapp.jsonor anexpodependency inpackage.json, so please verify manually:• In your example/app.json, ensure you have:
"sdkVersion": "<your-expo-sdk-version>"
and that version is ≥ 46 (required for Fabric & TurboModules).
• In your package.json, confirm you have anexpodependency matching that SDK (e.g."expo": "46.0.0"or newer).
• If you’re running plain React Native (no Expo), verify your RN version supports the new architecture (Fabric/TurboModules; typically RN ≥ 0.70+).You can spot-check by running:
grep -R '"sdkVersion"' -n example/app.json grep -R '"expo"' -n package.jsonIf these properties are missing or below the required versions, adjust them before enabling
newArchEnabled: true.example/android/build.gradle (3)
23-33: Repository configuration looks good.Including the local React Native Android directory alongside Google, Maven Central, and JitPack ensures all dependencies are resolved.
36-38:✅ Verification successful
Confirm plugin application order.
Applying
expo-root-projectbeforecom.facebook.react.rootprojectis correct. Verify that no plugin conflicts arise in your module graph when both are applied.Run:
🏁 Script executed:
#!/bin/bash # Check applied Gradle plugins grep apply plugin example/android/build.gradleLength of output: 227
Plugin application order verified
Both
expo-root-projectandcom.facebook.react.rootprojectare applied in the correct order (expo-root-projectfirst), and no conflicts were found in the module graph.
15-22:❓ Verification inconclusive
Validate dynamic React Native Android path resolution.
Resolving
react-nativevia Node is clever but may fail ifnodeisn’t in PATH. Please confirm this works in your CI environment or add a fallback.
🏁 Script executed:
#!/bin/bash # Test dynamic resolution of react-native Android directory node --print "console.log(require.resolve('react-native/package.json'))"Length of output: 847
Validate dynamic React Native Android path resolution
This lookup using
node --print "require.resolve('react-native/package.json')"relies on Node being in$PATHand on thereact-nativepackage being resolvable at build time. In our sandbox test it failed to locate the module, which suggests it may also break in certain CI or custom environments.Please verify that in all your build workflows (local, CI, docker, etc.):
nodeis available on thePATHrequire.resolve('react-native/package.json')correctly returns the package’s pathIf you cannot guarantee this, consider adding a fallback—for example defaulting to
"$rootDir/node_modules/react-native/android"or makingreactNativeAndroidDirconfigurable.example/ios/example/PrivacyInfo.xcprivacy (1)
1-49: Privacy declarations are correctly specified.The plist defines only accessed API categories with valid reason codes and disables tracking. This aligns with Apple’s privacy requirements for iOS 14+.
README.md (8)
51-63: Installation plugin steps are clear.The updated details for React Native CLI and Expo plugin configuration look correct. No changes needed here.
96-98: Example imports are accurate.Using
useState,useEffect, and thePipelineimport matches the API.
115-123: Model initialization parameters match new API.The model and decoder paths are correctly passed, and the custom
fetchoverride is implemented.
128-130: Error handling provides user feedback.Logging and alerting on load failure improves debuggability.
136-139: Text generation invocation is correct.Resetting output and invoking
generatewith a callback aligns with documented usage.
164-176: Custom download snippet is consistent.Using
expo-file-systemfor caching and progress callbacks follows best practices for Expo apps.
185-190: Progress logging is informative.The calculated percentage with
toFixed(1)provides clear feedback.
203-210: Supported models table updated.Reflecting recommended models and updated sizes is helpful for users.
example/android/gradlew.bat (4)
1-17: License header is intact.The Apache 2.0 license notice is correctly included at the top.
19-28: Environment detection is standard.Handling
Windows_NTand scoping variables ensures compatibility across shells.
39-47: JVM options and Java lookup are correct.Default JVM opts and the
JAVA_HOMEcheck match Gradle’s wrapper template.
73-78: Wrapper execution command is valid.Invoking
GradleWrapperMainwith provided JVM options is the expected pattern.example/android/gradle.properties (1)
1-59: LGTM! Well-configured Android Gradle properties.The configuration follows modern React Native and Expo best practices with appropriate memory allocation, architecture support, and feature enablement.
src/__tests__/text-embedding.pipeline.test.tsx (1)
1-57:❌ Incorrect review comment
Critical inconsistency: Test file exists for removed functionality.
This test file tests
TextEmbeddingPipelinefunctionality, but according to the changes insrc/index.tsx, all embedding-related exports have been removed from the public API. This creates an inconsistency where tests exist for functionality that's no longer available.Either:
- Remove this test file if embedding functionality is intentionally deprecated, or
- Restore embedding exports in
src/index.tsxif the functionality should remain availableLet me verify the current state of embedding functionality in the codebase:
🏁 Script executed:
#!/bin/bash # Check if TextEmbeddingPipeline is still used elsewhere in the codebase echo "Searching for TextEmbeddingPipeline usage:" rg -n "TextEmbeddingPipeline" --type typescript --type tsx echo -e "\nSearching for text-embedding pipeline file:" fd "text-embedding" --type f echo -e "\nChecking if TextEmbedding model still exists:" fd "text-embedding" --type f | head -5Length of output: 774
🏁 Script executed:
#!/bin/bash # Locate the main entry file(s) echo "Finding index files:" fd index.ts* --type f # Show exports in src/index.tsx (or .ts) if [ -f src/index.tsx ]; then echo -e "\n--- src/index.tsx (first 200 lines) ---" sed -n '1,200p' src/index.tsx elif [ -f src/index.ts ]; then echo -e "\n--- src/index.ts (first 200 lines) ---" sed -n '1,200p' src/index.ts else echo "No src/index.ts(x) found" fi # Inspect the TextEmbeddingPipeline implementation echo -e "\n--- src/pipelines/text-embedding.tsx (first 200 lines) ---" sed -n '1,200p' src/pipelines/text-embedding.tsxLength of output: 2981
Incorrect assumption: Embedding pipeline still exists and tests import it directly
The test file imports
TextEmbeddingPipelinestraight fromsrc/pipelines/text-embedding.tsx, and that file is still present in the codebase (along with its model insrc/models/text-embedding.tsx). Althoughsrc/index.tsxdoesn’t export the embedding pipeline on the public API, the tests don’t rely on the public export—they reference the internal module directly. There is therefore no broken import or failing test.If embedding is truly deprecated, you may want to remove both the pipeline implementation and its tests. Otherwise, leave the tests as-is (or update
src/index.tsxto re-expose the embedding pipeline if it should be part of the public API).Likely an incorrect or invalid review comment.
example/ios/example/Info.plist (1)
1-74: LGTM! Standard iOS Info.plist configuration.The Info.plist follows iOS best practices with appropriate security settings, version requirements, and app configuration. The NSAppTransportSecurity settings properly restrict arbitrary loads while allowing local networking for development.
example/src/App.tsx (1)
30-30: 🛠️ Refactor suggestionPotential runtime error with non-null assertion.
The non-null assertion operator (
!) onurl.split('/').pop()!could cause a runtime error if the URL doesn't contain any forward slashes.- const fileName = url.split('/').pop()!; + const fileName = url.split('/').pop() || 'model_file';Likely an incorrect or invalid review comment.
src/pipelines/text-embedding.tsx (1)
79-79: LGTM: Export formatting consistency.The single-line export format is more concise and maintains the same functionality.
eslint.config.mjs (1)
1-41: LGTM: Well-structured ESLint configuration.This is a properly configured modern ESLint setup using the flat config format with:
- Appropriate React Native and Prettier integration
- Correct compatibility layer usage for extending configs
- Sensible Prettier formatting rules
- Proper ignore patterns for build artifacts
The configuration follows current best practices for React Native projects.
babel.config.js (1)
2-11: LGTM: Appropriate Babel configuration for React Native libraries.The override-based structure correctly separates transformations:
- Source code uses
react-native-builder-bob/babel-presetfor library building- Dependencies use
@react-native/babel-presetfor React Native compatibilityThis is a standard and recommended pattern for React Native library projects.
src/__tests__/setup.js (1)
2-2: Standardize thetext-encoding-polyfillmock
The addition ofjest.mock('text-encoding-polyfill', () => ({}));cleanly isolates encoding dependencies in tests..github/workflows/ci.yml (1)
1-65: CI workflow looks solid
The jobs, triggers (includingmerge_group: checks_requested), and reuse of the composite setup action are well-structured for linting, testing, and multi-target builds.src/__tests__/text-generation.pipeline.test.tsx (1)
5-14: Mocks updated to use@huggingface/transformers
The migration from@xenova/transformersretains consistent mock behavior and single-quote style.example/android/app/src/main/res/drawable/rn_edit_text_material.xml (1)
1-38: Android drawable XML is well-formed and addresses the NPE issue
The<inset>wrapper and<selector>items correctly reference Material drawables, and the inline comment documents why the default item was removed to prevent NullPointerExceptions.example/android/app/src/main/AndroidManifest.xml (1)
1-25: AndroidManifest configuration aligns with application requirements
Permissions, deep-link<queries>, Expo updates metadata, and the launcher activity setup all match the new React Native + Expo integration.example/android/settings.gradle (2)
25-31: Good conditional autolinking configuration.The conditional logic for autolinking based on the
EXPO_USE_COMMUNITY_AUTOLINKINGenvironment variable provides good flexibility for different development scenarios. This follows Expo's recommended patterns.
39-39:❓ Verification inconclusive
Verify the
includeBuildreference matches earlier configuration.Ensure that
expoAutolinking.reactNativeGradlePluginreferences the same plugin path resolved earlier in thepluginManagementblock to maintain consistency.
🏁 Script executed:
#!/bin/bash # Check if there are any other references to reactNativeGradlePlugin in the Android configuration rg -A 2 -B 2 "reactNativeGradlePlugin" example/android/Length of output: 774
🏁 Script executed:
#!/bin/bash rg -n expoAutolinking example/android/settings.gradleLength of output: 263
🏁 Script executed:
#!/bin/bash sed -n '1,60p' example/android/settings.gradleLength of output: 1306
Confirm
includeBuildconsistencyPlease verify that the
expoAutolinking.reactNativeGradlePluginreference used at the root of your project resolves to the exact same path as thereactNativeGradlePluginyou defined in thepluginManagementblock. Keeping bothincludeBuildcalls in sync ensures you’re loading the identical Gradle plugin build in both contexts.• In
pluginManagement(lines 2–9):def reactNativeGradlePlugin = new File(…).getParentFile().absolutePath includeBuild(reactNativeGradlePlugin)• At the root (line 39):
includeBuild(expoAutolinking.reactNativeGradlePlugin)If these two resolve differently, consider unifying them (for example, by exposing your earlier
reactNativeGradlePluginvariable through the autolinking settings or by updating one to use the other).src/pipelines/text-generation.tsx (1)
30-30: Approve the consistent quote style changes.The changes from double quotes to single quotes improve code consistency throughout the file. The functional logic remains unchanged.
Also applies to: 42-42, 59-59, 62-62, 73-73, 85-85, 103-103, 118-118
example/package.json (4)
10-10: Good addition of patch-package tooling.The addition of patch-package and its postinstall script is a good practice for managing local patches to dependencies. This shows proper tooling setup for dependency management.
Also applies to: 18-19
4-4:✅ Verification successful
Verify the new entry point file exists.
The main entry point changed from "expo/AppEntry.js" to "index.js". Ensure the new entry point file exists and properly initializes the app.
🏁 Script executed:
#!/bin/bash # Check if the new entry point exists ls -la example/index.js cat example/index.jsLength of output: 424
Entry point verified:
example/index.jsexists and correctly registers the app withregisterRootComponent(App). No further action needed.
7-9:❓ Verification inconclusive
Verify the new Expo CLI commands work with current setup.
The scripts changed from
expo start --android/--iostoexpo run:android/ios. These commands require different setup and may need native development tools installed.
🌐 Web query:
What are the differences between "expo start --android" and "expo run:android" commands in Expo CLI? What are the requirements for each?💡 Result:
The commands
expo start --androidandexpo run:androidin Expo CLI serve related but distinct purposes when working with React Native projects using Expo. Here's a breakdown of their differences and requirements:
expo start --android
- Purpose: This command starts the Expo development server (Metro bundler) and then launches the Expo Go app on an Android device or emulator.
- How it works: It runs your JavaScript code within Expo Go, which is a pre-built client app that loads your project remotely.
- Requirements:
- Expo Go app installed on your Android device or emulator.
- An Android device connected via USB debugging or an Android emulator running.
- No native code compilation is performed—only JS bundling and running inside Expo Go.
- Use case: Best when you want to quickly test or develop your application using Expo's managed workflow without building a custom native app.
expo run:android
- Purpose: This command builds and runs your app as a standalone APK on an Android device or emulator.
- How it works: It compiles the native Android project (Java/Kotlin + React Native JS bundle) in your project, then installs and runs it on the device/emulator.
- Requirements:
- Native Android development environment set up (Android Studio, Android SDK, Java, etc.).
- Your project must be a "bare" or "custom" workflow project or a managed project with the bare workflow dependencies (since it involves native code compilation).
- An Android device connected or emulator running.
- Use case: Useful when you have custom native code or dependencies, or need to test a fully standalone app build on an actual device.
Summary Table
Feature expo start --androidexpo run:androidWhat it does Runs JS code in Expo Go on device/emulator Builds native APK and runs it on device Native code compilation? No Yes Requires Expo Go app? Yes No Requires Android Studio? No (only adb & emulator/device) Yes Workflow compatibility Managed workflow Bare/custom workflow or managed with bare Use case Quick development & testing Testing production-like native app If you want me to elaborate on setting up your environment for either command, just let me know!
Ensure native toolchain is in place for
expo runscriptsThe
package.jsonscripts have switched fromexpo start --android/--ios(which uses Expo Go) toexpo run:androidandexpo run:ios(which build and install native binaries). These require:
- Android
- Android Studio + Android SDK (including platform-tools) on your PATH
- A running emulator or USB-connected device
- iOS
- Xcode with Command Line Tools installed
- Simulator or a provisioned device
- For managed-workflow projects, make sure you’ve run
expo prebuildor have all bare-workflow dependencies in placePlease confirm your environment meets these requirements before merging.
14-14:❓ Verification inconclusive
Verify Expo SDK 53 compatibility.
Expo SDK 53 is a major upgrade from 51. Ensure all Expo modules and configurations are compatible with the new SDK version.
🌐 Web query:
What are the breaking changes and migration requirements for upgrading from Expo SDK 51 to SDK 53?💡 Result:
Upgrading from Expo SDK 51 to SDK 53 involves several significant changes and requirements. I'll provide a comprehensive guide to help you navigate this transition smoothly.
Major Changes in SDK 53
SDK 53 was released on April 30, 2025, and introduces substantial updates to the Expo ecosystem that developers need to be aware of before upgrading.
Core Framework Updates
- React Native 0.79: SDK 53 includes React Native 0.79, which is a significant version jump from SDK 51[6]
- React 19 Support: The latest SDK officially supports React 19, bringing new features and improvements[7]
- New Architecture By Default: The New Architecture is now enabled by default in SDK 53, whereas in previous versions it had to be manually enabled[4][6]
- Metro Bundler Changes: New stricter enforcement of
package.jsonexports in React Native 0.79, which may cause compatibility issues with third-party libraries[3]Android-Specific Changes
- Edge-to-edge display: SDK 53 introduces configuration for Android edge-to-edge display, requiring additional setup[3][7]
Upgrade Process
To ensure a smooth transition, I recommend taking an incremental approach when upgrading multiple SDK versions.
Step 1: Incremental Upgrade Path
If you're on SDK 51, consider upgrading to SDK 52 first, then to SDK 53, rather than jumping directly to SDK 53. This helps isolate and address issues specific to each version upgrade[1][3].
Step 2: Update Expo and Dependencies
For the actual upgrade to SDK 53:
Update the Expo package:
npx expo install expo@^53.0.0Update all dependencies to match the new SDK version:
npx expo install --fixIf you use EAS CLI, update it globally:
npm i -g eas-cli ```[6]Step 3: Handle Native Projects
- If using Continuous Native Generation: Delete the
androidandiosdirectories from your project so they can be regenerated with the new SDK1- If not using Continuous Native Generation: Run
npx pod-installif you have aniosdirectory, and consider adopting prebuild for easier future upgrades1Step 4: Address New Architecture Requirements
Since the New Architecture is now enabled by default in SDK 53, you need to:
- Verify that all your native modules and third-party libraries are compatible with the New Architecture
- If you encounter issues, you can temporarily opt out of the New Architecture while resolving compatibility problems[4][6]
- Run
npx expo-doctor@latestto check your dependencies against React Native Directory data[4][6]Step 5: Check for Deprecations and Removals
- Notable deprecation:
expo-background-fetchhas been replaced byexpo-background-task[3]- Review the "Deprecations, renamings, and removals" section in the SDK 53 changelog[6]
- Remove any outdated
resolutions/overridesin yourpackage.jsonthat might have been added for previous SDK versions[6]Common Issues and Troubleshooting
Several issues might arise during the upgrade process:
Third-party library compatibility: Not all libraries may be compatible with the New Architecture yet. Check for latest versions of your dependencies[4]
Node module resolution issues: Some users have reported errors with Node standard library module imports after upgrading to SDK 53, such as:
The package at "node_modules\ws\lib\stream.js" attempted to import the Node standard library module "stream" ```[8]Metro bundler and package.json exports: The stricter enforcement of
package.jsonexports may cause issues with third-party libraries that haven't adopted this standard[3]Development Environment Considerations
- Expo Go compatibility: Expo Go only supports the latest SDK version. If you rely heavily on Expo Go, consider its limitations[1][6]
- Development builds: For production apps, Expo recommends using development builds instead of Expo Go, as they provide better backward compatibility[1][6]
- Xcode requirements: Xcode 16 is needed for SDK 53, with Xcode 16.2+ being recommended[6]
By following this guide and being aware of the major changes, you should be able to successfully navigate the upgrade from Expo SDK 51 to SDK 53.
Citations:
- 1: https://docs.expo.dev/workflow/upgrading-expo-sdk-walkthrough/
- 2: https://www.youtube.com/watch?v=HBPyP4OxVgs
- 3: https://blog.logrocket.com/expo-sdk-53-checklist/
- 4: https://docs.expo.dev/guides/new-architecture/
- 5: https://abp.io/support/questions/7625/React-Native--Expo-migration?CurrentPage=3
- 6: https://expo.dev/changelog/sdk-53
- 7: https://www.youtube.com/watch?v=x-nhJcKYfOo
- 8: (upgrade from sdk 52 to expo sdk 53) The package at "node_modules\ws\lib\stream.js" attempted to import the Node standard library module "stream". expo/expo#36477
- 9: https://www.youtube.com/watch?v=U8Arc2ivj_o
- 10: https://github.com/orgs/community/discussions/158389
Ensure full compatibility with Expo SDK 53
Please verify and complete the following steps when upgrading from SDK 51 to SDK 53 in example/package.json (line 14):
- Incremental upgrade: if possible, go to SDK 52 first, then to SDK 53 to isolate issues.
- Update dependencies:
- Run
npx expo install expo@^53.0.0and thennpx expo install --fix.- Update global EAS CLI:
npm i -g eas-cli.- Native projects:
- If using prebuild, delete and regenerate your
android/iosfolders.- Otherwise run
npx pod-installin youriosdirectory.- New Architecture:
- Confirm all native modules and third-party libraries support React Native 0.79 & New Architecture (enabled by default).
- If issues arise, opt out temporarily or update the affected libraries.
- Deprecations & removals:
- Migrate from
expo-background-fetchtoexpo-background-task.- Remove outdated
resolutions/overridesin package.json.- Tooling & environment:
- Run
npx expo-doctor@latestto validate your setup.- Ensure Metro’s stricter package.json exports don’t break imports.
- Confirm Xcode 16.2+ (iOS) and configure Android edge-to-edge if used.
Refer to the SDK 53 changelog (https://expo.dev/changelog/sdk-53) and migration guide to address any other breaking changes.
.github/actions/setup/action.yml (2)
19-19: Excellent cache key strategy.The cache key correctly includes both
yarn.lockandpackage.jsonfiles while excludingnode_modulesdirectories. This ensures cache invalidation when dependencies change while avoiding circular references.
25-27: Good use of immutable installation.Using
yarn install --immutableis the correct approach for CI environments as it ensures reproducible builds and fails if the lockfile is outdated.example/android/app/src/main/java/transformers/example/MainActivity.kt (4)
48-60: Well-implemented Android version-specific back button handling.The back button implementation correctly handles the behavioral differences between Android versions, using
moveTaskToBack()for Android R and below while deferring to the default implementation for Android S and above. This aligns with Android's updated back button behavior guidelines.
32-41: Proper React Native new architecture integration.The
ReactActivityDelegateimplementation correctly usesReactActivityDelegateWrapperfor Expo integration and conditionally enables the new architecture based on build configuration. The structure follows React Native best practices.
26-26:✅ Verification successful
Verify main component registration.
The main component name is set to
"main". Ensure this matches the component registered in your React Native entry point (typically inindex.jsorApp.js).
🏁 Script executed:
#!/bin/bash # Check if the main component is registered correctly echo "Looking for main component registration:" rg -A 3 -B 3 "registerComponent.*main" example/ || echo "Main component registration not found" echo "Looking for AppRegistry usage:" rg -A 5 "AppRegistry" example/ || echo "AppRegistry usage not found"Length of output: 928
Component registration verified. The name returned by
getMainComponentName()(“main”) inMainActivity.ktmatches the default ID used byregisterRootComponent(App)inexample/index.js. No further changes needed.
18-20:✅ Verification successful
Verify the intentional null parameter in onCreate.
Passing
nullinstead ofsavedInstanceStatetosuper.onCreate()is intentional for expo-splash-screen integration, but this means the activity won't restore its previous state if recreated. Ensure this behavior aligns with your app's requirements.
🌐 Web query:
Does expo-splash-screen require passing null to super.onCreate() in React Native Android apps?💡 Result:
Yes, when integrating the
expo-splash-screenlibrary into a React Native Android application, it's necessary to callsuper.onCreate(null);in yourMainActivity.javafile. This ensures proper initialization of the React Native environment. Thenullargument is used because thesavedInstanceStateis not required in this context.Here's how you should modify your
MainActivity.java:import android.os.Bundle; import com.facebook.react.ReactActivity; import expo.modules.splashscreen.SplashScreen; import expo.modules.splashscreen.SplashScreenImageResizeMode; import com.facebook.react.ReactRootView; public class MainActivity extends ReactActivity { @Override protected void onCreate(Bundle savedInstanceState) { // This is required for expo-splash-screen. setTheme(R.style.AppTheme); super.onCreate(null); // SplashScreen.show(...) has to be called after super.onCreate(...) SplashScreen.show(this, SplashScreenImageResizeMode.CONTAIN, ReactRootView.class, false); } @Override protected String getMainComponentName() { return "YourAppName"; } }In this setup:
setTheme(R.style.AppTheme);sets the theme for your activity.super.onCreate(null);initializes the React Native environment.SplashScreen.show(...)displays the splash screen after the environment is set up.This configuration is recommended to ensure that the splash screen behaves correctly in your React Native Android application. (npmjs.com)
Citations:
Confirmed
super.onCreate(null)Is Intentional for Expo Splash Screen
- According to the expo-splash-screen docs, calling
super.onCreate(null)is required to properly initialize the React Native environment when using the splash-screen library.- Note that passing
nullmeans any previously saved activity state will not be restored. Please ensure this trade-off aligns with your app’s UX and state-restoration requirements.Location:
example/android/app/src/main/java/transformers/example/MainActivity.ktlines 18–20example/android/gradlew (2)
205-205: Default JVM options are appropriate for mobile development.The default JVM options
"-Xmx64m" "-Xms64m"provide reasonable memory allocation for Gradle wrapper execution. These values are conservative and suitable for most development environments.
1-252:✅ Verification successful
Standard Gradle wrapper script - no security concerns.
This is a standard Gradle-generated wrapper script with no suspicious modifications. The script properly handles cross-platform compatibility and follows POSIX compliance guidelines. Ensure the file has executable permissions.
🏁 Script executed:
#!/bin/bash # Verify the gradlew script has proper executable permissions if [ -f "example/android/gradlew" ]; then ls -la example/android/gradlew echo "File permissions check complete" else echo "gradlew file not found" fiLength of output: 215
Approved: Standard Gradle wrapper script with correct permissions
The Gradle‐generated
gradlewscript is unmodified and follows POSIX compliance and cross-platform guidelines. Executable permissions (-rwxr-xr-x) are correctly set onexample/android/gradlew. No further action required.example/android/app/src/main/java/transformers/example/MainApplication.kt (1)
1-57: Excellent React Native + Expo integration setup!This MainApplication class demonstrates a well-structured implementation that properly integrates React Native with Expo modules. The code correctly:
- Uses ReactNativeHostWrapper for Expo compatibility
- Configures the new architecture and Hermes flags based on build config
- Handles SoLoader initialization with merged native libraries
- Properly forwards lifecycle events to Expo's ApplicationLifecycleDispatcher
- Uses the correct JS main module path for Expo (
.expo/.virtual-metro-entry)The implementation follows React Native and Expo best practices and should work seamlessly with the new architecture.
example/android/app/build.gradle (1)
1-177: Excellent Android build configuration with modern React Native practices!This build script demonstrates several best practices:
- Dynamic path resolution: Uses Node.js commands to resolve React Native and Expo paths, ensuring compatibility across different environments
- Flexible configuration: Leverages project properties for optional features (Proguard, resource shrinking, bundle compression)
- Conditional dependencies: Smart handling of Fresco libraries based on GIF/WebP support flags
- Hermes/JSC selection: Proper conditional inclusion based on Hermes enablement
- Expo integration: Uses Expo CLI for bundling with correct Metro config support
The packaging options extension from gradle.properties (lines 133-148) is particularly well-implemented, providing a clean way to customize packaging behavior through configuration.
example/ios/example/AppDelegate.swift (1)
1-70: Clean and well-structured iOS AppDelegate implementation!This AppDelegate demonstrates excellent practices for Expo + React Native integration:
- Proper inheritance: Extends ExpoAppDelegate for seamless Expo integration
- Factory pattern: Clean setup of React Native factory and delegate
- Deep linking support: Comprehensive handling of both URL schemes and universal links
- Development vs. production: Smart bundle URL switching based on DEBUG flag
- Expo compatibility: Uses
.expo/.virtual-metro-entryfor development serverThe separation of concerns with the
ReactNativeDelegateclass is particularly good, keeping the bundle URL logic isolated and testable.package.json (13)
3-6: Verify version bump and entry points.Ensure the version bump to
0.1.0aligns with your release plan, and that./lib/module/index.jsand./lib/typescript/src/index.d.tsare correctly generated by your build process.
15-33: Approved: Explicitfilesfield for package contents.Your
filesarray clearly includes source and native folders while excluding build artifacts and test scaffolding, keeping the published package minimal.
46-48: Keywords updated for mobile platforms.Adding
"ios"and"android"improves discoverability on npm.
59-61: Publish config specifies the registry.Explicitly setting
publishConfig.registryhelps ensure the package is published to the intended npm registry.
63-73: Verify commitlint and ESLint setup.You’ve added
@commitlint/config-conventional,commitlint,@eslint/compat,@eslint/eslintrc,@eslint/js,@evilmartians/lefthook, and React Native ESLint presets. Confirm that thecommitlintCLI is installed correctly and that Lefthook hooks are configured to run both ESLint and commitlint as expected.
74-78: DevDependencies: Cleanup, linting, and testing tools.
del-cli,eslint,eslint-config-prettier,eslint-plugin-prettier, andjestare pinned to recent, compatible versions.
94-99: Root-level Jest configuration.The React Native preset and ignored paths (
example/node_modules,lib/) correctly scope your tests.
101-105: Commitlint configuration extends conventional.Your commitlint section properly extends
@commitlint/config-conventional.
106-123: Release-it configuration is sound.Using
--only-versionfor the script alongside the conventional-changelog plugin automates version bumps and changelog generation effectively.
125-131: Prettier style rules applied.Your formatting preferences (consistent quotes, trailing commas, tab width) are well-defined.
137-145: Verify build targets and TS config.Confirm that
tsconfig.build.jsonexists and thatreact-native-builder-bobproduces both the ESM module and TypeScript declaration outputs inlib.
150-154:create-react-native-libraryconfiguration.The scaffold settings (
languages,type,version) match your library requirements.
156-160: Verify GitHub dependency resolution.Pulling
@huggingface/transformersfrom a GitHub fork (#merge) can introduce variability. Please confirm that CI installs it reliably and consider pinning to a specific commit or tag.example/ios/example.xcodeproj/project.pbxproj (1)
1-542: Skip auto-generated Xcode project file review.This is an auto-generated Xcode workspace/project file; manual review is unlikely to surface actionable issues.
| - try { | ||
| - fs = require("@dr.pogodin/react-native-fs"); | ||
| - } catch {} | ||
| - if (!isLoaded()) { | ||
| - try { | ||
| - fs = require("react-native-fs"); | ||
| - } catch {} | ||
| - } | ||
| + // try { | ||
| + // fs = require("@dr.pogodin/react-native-fs"); | ||
| + // } catch {} | ||
| + // if (!isLoaded()) { | ||
| + // try { | ||
| + // fs = require("react-native-fs"); | ||
| + // } catch {} | ||
| + // } |
There was a problem hiding this comment.
💡 Verification agent
🧩 Analysis chain
Critical: This patch introduces a breaking change by removing filesystem library support.
The patch comments out the loading logic for @dr.pogodin/react-native-fs and react-native-fs, leaving only expo-file-system as the supported filesystem module. This is a significant breaking change that could affect users not using Expo.
Concerns:
- Breaking change: Applications relying on the removed libraries will fail
- Code quality: Commented code should be removed entirely, not left in place
- Patch fragility: Modifying third-party packages via patches requires maintenance on every update
Recommendations:
- Document this breaking change in release notes
- Consider forking the package instead of patching if this is a permanent change
- Remove commented code entirely
- // try {
- // fs = require("@dr.pogodin/react-native-fs");
- // } catch {}
- // if (!isLoaded()) {
- // try {
- // fs = require("react-native-fs");
- // } catch {}
- // }Let me verify if these removed libraries are still being used elsewhere in the codebase:
🏁 Script executed:
#!/bin/bash
# Description: Check if the removed filesystem libraries are referenced elsewhere
# Expected: Should find no remaining references to the removed libraries
echo "Searching for @dr.pogodin/react-native-fs references:"
rg -i "@dr\.pogodin/react-native-fs" --type js --type ts --type json
echo -e "\nSearching for react-native-fs references (excluding this patch):"
rg -i "react-native-fs" --type js --type ts --type json | grep -v "patches/native-universal-fs"
echo -e "\nChecking package.json files for these dependencies:"
fd "package\.json" --exec grep -l "react-native-fs\|@dr\.pogodin/react-native-fs" {}Length of output: 634
Breaking Change Confirmed – No Remaining References to Removed FS Libraries
We ran a search across the repository and found no other references to @dr.pogodin/react-native-fs or react-native-fs. That means removing those fallbacks is safe from a code-reference standpoint.
However, the patch still leaves commented‐out code in place, which reduces clarity and maintainability.
• Remove the commented-out require blocks entirely instead of leaving them in the patch.
• Document this breaking change in the release notes (call out dropping support for non-Expo FS libraries).
• Consider maintaining a fork or contributing upstream if this change must be permanent—and be prepared to reapply or update the patch on future versions.
- // try {
- // fs = require("@dr.pogodin/react-native-fs");
- // } catch {}
- // if (!isLoaded()) {
- // try {
- // fs = require("react-native-fs");
- // } catch {}
- // }📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| - try { | |
| - fs = require("@dr.pogodin/react-native-fs"); | |
| - } catch {} | |
| - if (!isLoaded()) { | |
| - try { | |
| - fs = require("react-native-fs"); | |
| - } catch {} | |
| - } | |
| + // try { | |
| + // fs = require("@dr.pogodin/react-native-fs"); | |
| + // } catch {} | |
| + // if (!isLoaded()) { | |
| + // try { | |
| + // fs = require("react-native-fs"); | |
| + // } catch {} | |
| + // } |
🤖 Prompt for AI Agents
In patches/native-universal-fs+0.2.0.patch around lines 9 to 24, the code
comments out the require statements for @dr.pogodin/react-native-fs and
react-native-fs, which removes support for these filesystem libraries. To fix
this, completely remove these commented-out require blocks instead of leaving
them in the patch to improve code clarity and maintainability. Additionally,
ensure this breaking change is documented in the release notes, highlighting the
dropped support for non-Expo filesystem libraries, and consider maintaining a
fork or contributing upstream if this change is permanent.
| <color name="splashscreen_background">#ffffff</color> | ||
| <color name="iconBackground">#ffffff</color> | ||
| <color name="colorPrimary">#023c69</color> | ||
| <color name="colorPrimaryDark">#ffffff</color> |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Reconsider the colorPrimaryDark value.
Setting colorPrimaryDark to white (#ffffff) is unusual and contradicts typical Material Design conventions where the primary dark color should be darker than the primary color. This may cause theming inconsistencies.
Consider using a darker shade of your primary color:
- <color name="colorPrimaryDark">#ffffff</color>
+ <color name="colorPrimaryDark">#012a4a</color>📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| <color name="colorPrimaryDark">#ffffff</color> | |
| <color name="colorPrimaryDark">#012a4a</color> |
🤖 Prompt for AI Agents
In example/android/app/src/main/res/values/colors.xml at line 5, the
colorPrimaryDark is set to white (#ffffff), which is not typical as it should be
a darker shade than the primary color to follow Material Design guidelines.
Change the colorPrimaryDark value to a darker shade of your primary color to
ensure consistent theming and better visual hierarchy.
| @@ -0,0 +1 @@ | |||
| <resources/> | |||
There was a problem hiding this comment.
🛠️ Refactor suggestion
Implement night mode color resources.
The empty night mode colors file means users won't get proper dark theme support. Consider defining appropriate dark theme colors that complement the light theme.
Here's a suggested implementation for night mode colors:
-<resources/>
+<resources>
+ <color name="splashscreen_background">#121212</color>
+ <color name="iconBackground">#1f1f1f</color>
+ <color name="colorPrimary">#4a90e2</color>
+ <color name="colorPrimaryDark">#2c5aa0</color>
+</resources>These colors follow Material Design dark theme guidelines and provide good contrast ratios.
🤖 Prompt for AI Agents
In example/android/app/src/main/res/values-night/colors.xml at line 1, the file
is currently empty, which means no colors are defined for night mode, resulting
in lack of dark theme support. To fix this, define appropriate dark theme color
resources that complement the light theme, following Material Design dark theme
guidelines. Add color definitions with suitable dark background and contrasting
text colors to ensure proper night mode appearance.
| # pre-commit: | ||
| # parallel: true | ||
| # commands: | ||
| # lint: | ||
| # glob: '*.{js,ts,jsx,tsx}' | ||
| # run: npx eslint {staged_files} | ||
| # types: | ||
| # glob: '*.{js,ts, jsx, tsx}' | ||
| # run: npx tsc | ||
| # commit-msg: | ||
| # parallel: true | ||
| # commands: | ||
| # commitlint: | ||
| # run: npx commitlint --edit |
There was a problem hiding this comment.
Enable Lefthook hooks by uncommenting the configuration.
Currently all lines are commented out, so Lefthook won’t detect any hooks. Remove the leading # markers to activate your pre-commit and commit-msg hooks:
-# pre-commit:
-# parallel: true
-# commands:
-# lint:
-# glob: '*.{js,ts,jsx,tsx}'
-# run: npx eslint {staged_files}
-# types:
-# glob: '*.{js,ts, jsx, tsx}'
-# run: npx tsc
-# commit-msg:
-# parallel: true
-# commands:
-# commitlint:
-# run: npx commitlint --edit
+pre-commit:
+ parallel: true
+ commands:
+ lint:
+ glob: '*.{js,ts,jsx,tsx}'
+ run: npx eslint {staged_files}
+ types:
+ glob: '*.{js,ts, jsx, tsx}'
+ run: npx tsc
+commit-msg:
+ parallel: true
+ commands:
+ commitlint:
+ run: npx commitlint --edit📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| # pre-commit: | |
| # parallel: true | |
| # commands: | |
| # lint: | |
| # glob: '*.{js,ts,jsx,tsx}' | |
| # run: npx eslint {staged_files} | |
| # types: | |
| # glob: '*.{js,ts, jsx, tsx}' | |
| # run: npx tsc | |
| # commit-msg: | |
| # parallel: true | |
| # commands: | |
| # commitlint: | |
| # run: npx commitlint --edit | |
| pre-commit: | |
| parallel: true | |
| commands: | |
| lint: | |
| glob: '*.{js,ts,jsx,tsx}' | |
| run: npx eslint {staged_files} | |
| types: | |
| glob: '*.{js,ts, jsx, tsx}' | |
| run: npx tsc | |
| commit-msg: | |
| parallel: true | |
| commands: | |
| commitlint: | |
| run: npx commitlint --edit |
🤖 Prompt for AI Agents
In lefthook.yml from lines 1 to 14, all configuration lines are commented out,
preventing Lefthook from detecting any hooks. Remove the leading '#' characters
from each line to uncomment and activate the pre-commit and commit-msg hook
configurations.
| classpath('com.android.tools.build:gradle') | ||
| classpath('com.facebook.react:react-native-gradle-plugin') | ||
| classpath('org.jetbrains.kotlin:kotlin-gradle-plugin') |
There was a problem hiding this comment.
Pin Gradle plugin versions.
Currently, the classpath entries omit explicit versions, which can lead to build instability. It’s best practice to declare versions for reproducible builds.
Apply a diff like:
-dependencies {
- classpath('com.android.tools.build:gradle')
- classpath('com.facebook.react:react-native-gradle-plugin')
- classpath('org.jetbrains.kotlin:kotlin-gradle-plugin')
-}
+dependencies {
+ classpath("com.android.tools.build:gradle:7.4.2")
+ classpath("com.facebook.react:react-native-gradle-plugin:0.71.8")
+ classpath("org.jetbrains.kotlin:kotlin-gradle-plugin:1.8.20")
+}📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| classpath('com.android.tools.build:gradle') | |
| classpath('com.facebook.react:react-native-gradle-plugin') | |
| classpath('org.jetbrains.kotlin:kotlin-gradle-plugin') | |
| dependencies { | |
| classpath("com.android.tools.build:gradle:7.4.2") | |
| classpath("com.facebook.react:react-native-gradle-plugin:0.71.8") | |
| classpath("org.jetbrains.kotlin:kotlin-gradle-plugin:1.8.20") | |
| } |
🤖 Prompt for AI Agents
In example/android/build.gradle around lines 9 to 11, the classpath dependencies
for the Android Gradle plugin, React Native Gradle plugin, and Kotlin Gradle
plugin lack explicit version numbers. To ensure build stability and
reproducibility, specify exact version numbers for each classpath entry by
adding the appropriate version strings to the dependency declarations.
| <imageView id="EXPO-SplashScreen" userLabel="SplashScreenLogo" image="SplashScreenLogo" contentMode="scaleAspectFit" clipsSubviews="true" userInteractionEnabled="false" translatesAutoresizingMaskIntoConstraints="false"> | ||
| <rect key="frame" x="0" y="0" width="414" height="736"/> | ||
| </imageView> |
There was a problem hiding this comment.
💡 Verification agent
🧩 Analysis chain
Verify the splash screen image dimensions and aspect ratio.
The image view references SplashScreenLogo with fixed dimensions (414x736), but uses scaleAspectFit content mode. Ensure the referenced image asset exists and has appropriate dimensions for different device sizes.
🏁 Script executed:
#!/bin/bash
# Check if the splash screen assets exist in the iOS project
fd -t f "SplashScreenLogo" example/ios/
fd -t f -e xcassets example/ios/Length of output: 428
🏁 Script executed:
#!/bin/bash
# Locate asset catalog directories
fd -t d -e xcassets example/ios
# Find any SplashScreenLogo asset set
fd -t d "SplashScreenLogo.imageset" example/ios
# Search for image files matching the SplashScreenLogo pattern
find example/ios -type f -iname "*SplashScreenLogo*.png"
# Confirm storyboard references
rg -n "SplashScreenLogo" -R example/iosLength of output: 998
🏁 Script executed:
#!/bin/bash
# Locate the SplashScreen.storyboard file
echo "Storyboard path:"
fd -t f "SplashScreen.storyboard" -e storyboard example/ios
# List contents of the SplashScreenLogo asset set
echo "Files in SplashScreenLogo.imageset:"
find example/ios/example/Images.xcassets/SplashScreenLogo.imageset -maxdepth 1 -type f
# Show image filenames declared in Contents.json
echo "Declared filenames in Contents.json:"
jq '.images[].filename' example/ios/example/Images.xcassets/SplashScreenLogo.imageset/Contents.json
# Extract constraint and safe area references from the storyboard
echo "Constraints around the splash image view:"
rg -n "<constraint" -A 3 -B 3 example/ios/example/SplashScreen.storyboard
echo "Safe area references:"
rg -n "safeArea" -A 2 -B 2 example/ios/example/SplashScreen.storyboardLength of output: 2701
🏁 Script executed:
#!/bin/bash
# Print dimensions of splash screen image assets
file example/ios/example/Images.xcassets/SplashScreenLogo.imageset/image.png
file example/ios/example/Images.xcassets/SplashScreenLogo.imageset/image@2x.png
file example/ios/example/Images.xcassets/SplashScreenLogo.imageset/image@3x.pngLength of output: 527
🏁 Script executed:
#!/bin/bash
# Install Pillow to inspect image dimensions
pip install --quiet pillow
# Python script to print dimensions of splash screen assets
python3 - << 'EOF'
from PIL import Image
import os
asset_dir = "example/ios/example/Images.xcassets/SplashScreenLogo.imageset"
for filename in ["image.png", "image@2x.png", "image@3x.png"]:
path = os.path.join(asset_dir, filename)
if os.path.isfile(path):
try:
with Image.open(path) as img:
print(f"{filename}: {img.size[0]}x{img.size[1]}")
except Exception as e:
print(f"Error reading {filename}: {e}")
else:
print(f"{filename} not found")
EOFLength of output: 109
Adjust logo constraints and asset scales
-
Verified assets exist at
example/ios/example/Images.xcassets/SplashScreenLogo.imagesetwithimage.png,image@2x.png,image@3x.png(all 1024×1024). To avoid unintended up/down-scaling, either supply proper @2x (2048×2048) & @3x (3072×3072) versions or resize the base asset to match its intended display size in points. -
In
example/ios/example/SplashScreen.storyboard(lines 25–28), the logo image view is pinned to all edges ofEXPO-ContainerView, effectively stretching a square logo to fullscreen. For a logo, switch to centering plus explicit size or aspect-ratio constraints:
Replace existing edge constraints:
<constraint firstItem="EXPO-SplashScreen" firstAttribute="top" secondItem="EXPO-ContainerView" secondAttribute="top" id="…"/>
<constraint firstItem="EXPO-SplashScreen" firstAttribute="leading" secondItem="EXPO-ContainerView" secondAttribute="leading" id="…"/>
<constraint firstItem="EXPO-SplashScreen" firstAttribute="trailing" secondItem="EXPO-ContainerView" secondAttribute="trailing" id="…"/>
<constraint firstItem="EXPO-SplashScreen" firstAttribute="bottom" secondItem="EXPO-ContainerView" secondAttribute="bottom" id="…"/>With centered sizing:
<constraint firstItem="EXPO-SplashScreen" firstAttribute="centerX" secondItem="EXPO-ContainerView" secondAttribute="centerX" id="…"/>
<constraint firstItem="EXPO-SplashScreen" firstAttribute="centerY" secondItem="EXPO-ContainerView" secondAttribute="centerY" id="…"/>
<constraint firstItem="EXPO-SplashScreen" firstAttribute="width" constant="LOGO_WIDTH" id="…"/>
<constraint firstItem="EXPO-SplashScreen" firstAttribute="height" constant="LOGO_HEIGHT" id="…"/>Alternatively, add an aspect-ratio constraint if dynamic sizing is preferred. This ensures your logo retains its intended dimensions and aspect ratio across all devices.
🤖 Prompt for AI Agents
In example/ios/example/SplashScreen.storyboard around lines 19 to 28, the splash
screen logo image view uses fixed edge constraints that stretch the square logo
to fullscreen, causing distortion. Replace these edge constraints with
constraints that center the image view within its container and set explicit
width and height constants matching the logo's intended display size, or add an
aspect-ratio constraint to preserve the logo's proportions. Also, ensure the
image assets have appropriate @2x and @3x resolutions or resize the base asset
to avoid scaling issues.
| PreTrainedTokenizer, | ||
| } from '@huggingface/transformers'; | ||
| import { TextGeneration as Model } from '../models/text-generation'; | ||
| import { LoadOptions } from '../models/base'; |
There was a problem hiding this comment.
Fix type-only import violation.
The LoadOptions import must be a type-only import when verbatimModuleSyntax is enabled.
-import { LoadOptions } from '../models/base';
+import type { LoadOptions } from '../models/base';🧰 Tools
🪛 GitHub Actions: CI
[error] 7-7: 'LoadOptions' is a type and must be imported using a type-only import when 'verbatimModuleSyntax' is enabled. (TS1484)
🤖 Prompt for AI Agents
In src/pipelines/text-generation.tsx at line 7, the import of LoadOptions should
be changed to a type-only import to comply with the verbatimModuleSyntax
setting. Modify the import statement to use the `import type` syntax for
LoadOptions, ensuring it is imported solely as a type without including any
runtime code.
| import { | ||
| env, | ||
| AutoTokenizer, | ||
| PreTrainedTokenizer, | ||
| } from '@huggingface/transformers'; |
There was a problem hiding this comment.
💡 Verification agent
🧩 Analysis chain
Critical: Module '@huggingface/transformers' not found.
The pipeline failure indicates that the module @huggingface/transformers cannot be found. This suggests the dependency may not be installed or the package name is incorrect.
Verify the correct package name and ensure it's installed:
🏁 Script executed:
#!/bin/bash
# Check if the package is available on npm and what its correct name is
curl -s "https://registry.npmjs.org/@huggingface/transformers" | jq '.name // "Package not found"'
# Check what transformers packages are available from Hugging Face
curl -s "https://registry.npmjs.org/-/v1/search?text=@huggingface+transformers" | jq '.objects[].package.name'
# Check current package.json for transformers dependencies
cat package.json | jq '.dependencies, .devDependencies' | grep -i transformLength of output: 6112
🏁 Script executed:
#!/bin/bash
# Locate package.json in the repository
fd package.json -t f
# Search for @huggingface/transformers in package.json
for file in $(fd package.json -t f); do
echo "=== $file ==="
rg -n '"@huggingface/transformers"' "$file" || echo " • @huggingface/transformers not referenced"
doneLength of output: 564
Update: ‘@huggingface/transformers’ is already declared in package.json
The import path is correct—line 156 of package.json references
"@huggingface/transformers": "github:mybigday/transformers.js-rn#merge"If you’re seeing “module not found,” please ensure you’ve run npm install (or yarn) and that your bundler supports GitHub‐hosted dependencies.
Remaining fixes still apply:
• Convert any LoadOptions import to a type‐only import:
-import { LoadOptions, … } from '@huggingface/transformers';
+import type { LoadOptions } from '@huggingface/transformers';• Verify that AutoTokenizer and PreTrainedTokenizer APIs match the version you’ve migrated to.
🧰 Tools
🪛 GitHub Actions: CI
[error] 5-5: Cannot find module '@huggingface/transformers' or its corresponding type declarations. (TS2307)
🤖 Prompt for AI Agents
In src/pipelines/text-generation.tsx around lines 1 to 5, the module
'@huggingface/transformers' is reported as not found despite being declared in
package.json via a GitHub-hosted dependency. First, ensure you have run 'npm
install' or 'yarn' to install all dependencies. Confirm your bundler supports
GitHub-hosted packages. Additionally, convert any imports of LoadOptions to
type-only imports to avoid runtime issues. Finally, verify that the usage of
AutoTokenizer and PreTrainedTokenizer matches the API of the installed version
and update the code accordingly if there are any breaking changes.
| "react": "19.0.0", | ||
| "react-dom": "19.0.0", | ||
| "react-native": "0.79.2", |
There was a problem hiding this comment.
💡 Verification agent
🧩 Analysis chain
Verify compatibility of major version upgrades.
React 19.0.0 and React Native 0.79.2 are significant upgrades that may introduce breaking changes. Ensure thorough testing of the application with these new versions.
🌐 Web query:
What are the breaking changes in React 19.0.0 and React Native 0.79.2? Are they compatible with each other?
💡 Result:
React 19.0.0 and the latest React Native versions introduce several breaking changes that developers need to address when upgrading. Based on the latest information available, React 19 is indeed compatible with React Native, but requires careful attention to breaking changes in both libraries.
React 19.0.0 Breaking Changes
Removed APIs and Features
String Refs
String refs were initially deprecated in March 2018 (v16.3.0) and have now been completely removed in React 19. You'll need to migrate to ref callbacks instead[1].
// Before
class MyComponent extends React.Component {
componentDidMount() {
this.refs.input.focus();
}
render() {
return <input ref='input' />;
}
}
// After
class MyComponent extends React.Component {
componentDidMount() {
this.input.focus();
}
render() {
return <input ref={input => this.input = input} />;
}
}React.createFactory
The createFactory API was deprecated in February 2020 (v16.13.0) and has been removed in React 19. Developers should migrate to JSX instead[1].
PropTypes
PropTypes have been removed in React 19, requiring you to adjust your app to make it compatible with the new version[5].
useRef Changes
The useRef() function now always requires an argument. Previously, it would create a ref with an undefined initial value if no argument was provided. You'll need to replace useRef() with useRef(undefined) where necessary[8].
Type changes for refs are also significant:
useRef<T>(null)now returnsRefObject<T|null>instead ofRefObject<T>useRef<T>(someValueOfT)returnsRefObject<T>withcurrenttyped asTrather thanT|null[8]
StrictMode Behavior Changes
In React 19's Strict Mode, useMemo and useCallback now reuse memoized results from the first render during the second render. This may affect components that aren't fully Strict Mode compatible[1].
Suspense Improvements
React 19 changes how Suspense works. When a component suspends, React will immediately commit the fallback of the nearest Suspense boundary without waiting for the entire sibling tree to render. After committing the fallback, React schedules another render for suspended siblings to "pre-warm" lazy requests[1].
React Native Changes
React Native 0.78 and 0.79
React Native 0.78 first introduced React 19 support[5], and React Native 0.79 continues with this compatibility while adding its own breaking changes.
Module Import Changes
Deep imports to modules inside React Native libraries with require syntax now require appending an explicit .default. This affects numerous libraries including Alert, ActionSheetIOS, BatchedBridge, AppState, and many others[6].
Removal of Remote JS Debugging
React Native 0.79 has removed Remote JS Debugging via Chrome, which was deprecated in version 0.73. Developers should now use React Native DevTools for debugging. This also means React Native is no longer compatible with the react-native-debugger community project[9].
CSS Compliance Updates
- Unitless lengths in
box-shadowandfilterare no longer supported. For example,1 1 blackshould be replaced with1px 1px black - Incorrect hwb() syntax support has been removed from normalize-color. Comma-separated values like
hwb(0, 0%, 100%)should be replaced withhwb(0 0% 100%)[9]
ExceptionsManager Export Update
The ExceptionsManager module now exports a default ExceptionsManager object, with SyntheticError as a secondary export[9].
Compatibility and Upgrade Process
React 19 is fully supported in React Native starting from version 0.78[5]. When upgrading, you'll need to:
- Update Dependencies: Modify your package.json to use the correct versions:
"dependencies": {
"react": "19.0.0",
"react-native": "0.79.0"
}- Install Updates:
npm install
npx react-native upgrade-
Update Native Code: Update native code for both iOS and Android platforms depending on your project configuration[4].
-
Address Breaking Changes: Review and fix all breaking changes from both React 19 and the new React Native version[3].
-
Test Thoroughly: Use React 19's new
<StrictMode>to identify deprecated APIs and thoroughly test component unmount behavior, as React 19 cleans up effects more aggressively[2]. -
Check Third-Party Dependencies: Ensure all your third-party libraries are compatible with React 19 before upgrading[2].
The process requires careful planning, but the performance improvements, bug fixes, and new features make the upgrade worthwhile for most applications.
Citations:
- 1: https://react.dev/blog/2024/04/25/react-19-upgrade-guide
- 2: https://blog.openreplay.com/common-mistakes-upgrading-react-19-avoid/
- 3: https://www.ifourtechnolab.com/blog/react-18-vs-react-19-key-differences-to-know-for-2024
- 4: https://www.lucentinnovation.com/blogs/it-insights/react-native-0-78-react-19-version-update-guide
- 5: https://reactnative.dev/blog/2025/02/19/react-native-0.78
- 6: https://github.com/facebook/react-native/releases
- 7: Build failure with react-native 0.79.0 callstack/react-native-builder-bob#813
- 8: https://www.thecandidstartup.org/2025/03/31/vitest-3-vite-6-react-19.html
- 9: https://reactnative.dev/blog/2025/04/08/react-native-0.79
- 10: https://www.iflair.com/why-should-we-upgrade-react-native-versions-for-mobile-development/
Verify and Migrate Breaking Changes for React 19.0.0 & React Native 0.79.2
File: example/package.json
Lines: 20–22
"react": "19.0.0",
"react-dom": "19.0.0",
"react-native": "0.79.2",React 19 and React Native 0.79 are compatible (RN added React 19 support in 0.78), but they introduce multiple breaking changes. Before merging:
• Migrate all string refs to callback refs
• Remove any uses of React.createFactory (use JSX)
• Extract or replace PropTypes (they’ve been removed from core)
• Add explicit arguments to useRef() (e.g. useRef(undefined)) and adjust types
• Verify your components under StrictMode (new reuse behavior for useMemo/useCallback)
• Audit any Suspense boundaries—fallbacks now commit earlier
• In React Native, update deep imports to append .default (Alert, AppState, etc.)
• Remove or replace Remote JS debugging code—use React Native DevTools
• Fix unitless lengths in CSS (box-shadow, filter) and update hwb() syntax
• Update ExceptionsManager imports to use its default export
• Confirm all third-party libraries you depend on support React 19
After these migrations, run:
npm install
npx react-native upgrade
# Update native iOS/Android code per the RN upgrade guideThen thoroughly test the app—ideally under <StrictMode>—to catch any residual issues.
🤖 Prompt for AI Agents
In example/package.json lines 20 to 22, you have upgraded to React 19.0.0 and
React Native 0.79.2, which are compatible but introduce breaking changes. To fix
this, migrate all string refs to callback refs, remove React.createFactory usage
in favor of JSX, replace or remove PropTypes, add explicit arguments to useRef
calls, and verify components under StrictMode. For React Native, update deep
imports to append .default, remove Remote JS debugging code and switch to React
Native DevTools, fix CSS unitless lengths and hwb() syntax, update
ExceptionsManager imports to use the default export, and ensure all third-party
libraries support React 19. After these changes, run npm install and npx
react-native upgrade, update native iOS/Android code as needed, and thoroughly
test the app.
| buildForAnalyzing = "YES"> | ||
| <BuildableReference | ||
| BuildableIdentifier = "primary" | ||
| BlueprintIdentifier = "13B07F861A680F5B00A75B9A" |
There was a problem hiding this comment.
💡 Verification agent
🧩 Analysis chain
Verify blueprint identifier consistency.
The blueprint identifiers 13B07F861A680F5B00A75B9A (main app) and 00E356ED1AD99517003FC87E (test target) are referenced consistently throughout the scheme. Ensure these match the actual target identifiers in the Xcode project file.
Also applies to: 35-35, 57-57, 74-74
🏁 Script executed:
#!/bin/bash
# Verify that the blueprint identifiers exist in the project file
if [ -f "example/ios/example.xcodeproj/project.pbxproj" ]; then
echo "Checking for main app blueprint identifier:"
grep -n "13B07F861A680F5B00A75B9A" example/ios/example.xcodeproj/project.pbxproj || echo "Main app identifier not found"
echo "Checking for test target blueprint identifier:"
grep -n "00E356ED1AD99517003FC87E" example/ios/example.xcodeproj/project.pbxproj || echo "Test target identifier not found"
else
echo "Project file not found - cannot verify blueprint identifiers"
fiLength of output: 630
🏁 Script executed:
#!/bin/bash
# Locate the actual test target identifier for "exampleTests"
echo "Searching for 'exampleTests' entries in project.pbxproj:"
grep -n "/* exampleTests */" example/ios/example.xcodeproj/project.pbxproj | sed -E 's/^([0-9]+):\s*([A-F0-9]{24}).*/Line \1: Target identifier: \2/'Length of output: 280
🏁 Script executed:
#!/bin/bash
pbx="example/ios/example.xcodeproj/project.pbxproj"
echo "Listing native targets with 'Tests' in their name:"
grep -niE '^[[:space:]]*[A-F0-9]{24} /\* .*tests' "$pbx" || echo "No test targets found"Length of output: 319
Fix missing test target blueprint identifier in scheme
The scheme references a test target with blueprint identifier 00E356ED1AD99517003FC87E, but that ID isn’t present in
example/ios/example.xcodeproj/project.pbxproj. Please:
- Open
example/ios/example.xcodeproj/xcshareddata/xcschemes/example.xcschemeand update theBlueprintIdentifierfor the Test actions at:- Line 35
- Line 57
- Line 74
Replace00E356ED1AD99517003FC87Ewith the actual test-target ID from your project file.
- Locate the correct ID by finding the
PBXNativeTargetentry for your test bundle in
example/ios/example.xcodeproj/project.pbxproj. - If the test target has been renamed or removed, update or remove the Test action in the scheme accordingly.
🤖 Prompt for AI Agents
In example/ios/example.xcodeproj/xcshareddata/xcschemes/example.xcscheme at
lines 35, 57, and 74, the BlueprintIdentifier for the Test actions currently
uses the ID 00E356ED1AD99517003FC87E, which does not exist in the
project.pbxproj file. To fix this, open
example/ios/example.xcodeproj/project.pbxproj, locate the PBXNativeTarget entry
for your test bundle to find the correct test target ID, then update the
BlueprintIdentifier values at those lines in the scheme file to this correct ID.
If the test target has been renamed or removed, update or remove the
corresponding Test action in the scheme accordingly.
Summary by CodeRabbit
New Features
Bug Fixes
@huggingface/transformersand React Native versions.Documentation
Chores
.gitignorefiles for proper exclusion of build artifacts and environment files.Tests