feat: bump nitro codegen to nitrogen 0.35.2 and upstream auto-size-input event sync by weatherstar · Pull Request #83 · OneKeyHQ/app-modules

weatherstar · 2026-08-14T02:37:53Z

Summary

Bump nitrogen and react-native-nitro-modules from 0.31.10 / 0.33.2 to 0.35.2 across all 20 nitro packages, the example app, and the create-module/view templates, so the next release ships 0.35-compatible codegen.
Add a post-nitrogen script in react-native-chart-webview that marks the generated Android view manager open (nitrogen ≥ 0.35 emits it final; TeardownChartWebviewManager must subclass it to dispose the non-pooled WebView on drop).
Upstream the mostRecentEventCount text-update sync that app-monorepo has been carrying as a patch-package patch on @onekeyfe/react-native-auto-size-input 3.0.78 (Android impl + unit tests, iOS counterpart, .nitro.ts spec).

Why

The Onramper headless SDK (app-monorepo PR OneKeyHQ/app-monorepo#12875) hard-requires react-native-nitro-modules ≥ 0.35 in the consuming app, and nitro codegen is not compatible across that boundary: 0.35 moved the Kotlin JNI binding into a nested CxxPart, so packages generated with older nitrogen fail to compile on Android against the 0.35 runtime. app-monorepo currently works around this with 21 patch-package patches that regenerate codegen inside node_modules (commit a71d5c1fff there). Landing the upgrade here and releasing lets the app delete all of those patches, per huanming's suggestion (Slack, 2026-08-14).

Verification

nitrogen runs clean for all 20 nitro packages; typecheck passes for every workspace.
Regenerated output was diffed against the on-device-verified patch state in app-monorepo (local Android bundleGoogleRelease + iOS Release builds): 18/20 packages byte-identical; chart-webview differs only by the explanatory comment next to the open modifier; range-downloader differs only where its sources moved past 3.0.78 (firmware-archive additions).
The auto-size-input Kotlin unit test (TextUpdateEventCounterTest) is included; the same implementation has been shipping inside the app via the patch.

Release coordination

Codegen incompatibility is bidirectional: packages released from this branch require react-native-nitro-modules ≥ 0.35 in the app. app-monorepo x is still on 0.33.2, so the new versions must land there together with the nitro bump (PR #12875) — please coordinate the npm release (3.0.82 or next tag first) so x doesn't pick it up standalone.

Upstreams the change app-monorepo has carried as a patch-package patch on @onekeyfe/react-native-auto-size-input 3.0.78: expose mostRecentEventCount on the AutoSizeInput hybrid view and count text-update events natively (TextUpdateEventCounter) so the JS side can drop stale controlled-input updates. Ships the Android implementation with unit tests and the iOS counterpart.

The Onramper headless SDK requires react-native-nitro-modules >= 0.35 in the consuming app, and nitro codegen is not compatible across that boundary: 0.35 moved the Kotlin JNI binding into a nested CxxPart and packages generated with older nitrogen fail to compile against the 0.35 runtime. Bumps nitrogen and react-native-nitro-modules (dev + peer) to 0.35.2 across all nitro packages, the example app, and the create-module/view templates, so the next release ships 0.35-compatible codegen. nitrogen >= 0.35 also emits the Android view manager as a final class; chart-webview needs it open so TeardownChartWebviewManager can subclass it to dispose the non-pooled WebView on drop. A post-nitrogen script now reapplies the open modifier on every codegen pass. Verified: regenerated output for all 20 nitro packages matches the patch-package patches app-monorepo has been building and running on-device (commit a71d5c1fff there), byte-identical except range-downloader (newer sources here) and the chart-webview open modifier.

socket-security · 2026-08-14T02:38:45Z

Review the following changes in direct dependencies. Learn more about Socket for GitHub.

Package	Supply Chain Security	Quality	Maintenance
npm/react-native-mmkv@4.1.2 ⏵ 4.2.0	⁺¹	⁺¹	^-3
npm/nitrogen@0.31.10 ⏵ 0.35.2	⁺⁹	⁺¹	⁺²
npm/react-native-nitro-modules@0.33.2 ⏵ 0.35.2	⁺¹	⁺¹

View full report

…nts on iOS Addresses review on the mostRecentEventCount protocol: - Android: participation is now opt-in. TextUpdateEventCounter keeps mostRecentEventCount nullable; callers that never supply the count bypass stale-update filtering entirely, so programmatic clears/sanitization/form restores keep applying after native edits. Regression covered by unit tests. - iOS: both delegate change callbacks (editingChanged / textViewDidChange, user edits only) now bump a native event count, and the text setter rejects stale controlled updates for participating callers, realigning the stored prop with the displayed text; uncounted callers keep full control, matching Android.

weatherstar · 2026-08-14T03:04:47Z

Both handled:

Code review: the two P2s were fixed in 330c078 (Android: stale-update filtering is now opt-in — callers that never supply mostRecentEventCount always apply, with regression unit tests, 8/8 passing via testDebugUnitTest; iOS: both delegate change paths now track the native event count and the text setter rejects stale controlled updates). Detailed notes are in the inline replies.
Versions: bumped all packages to 3.0.82 via yarn version:patch (81b8196). Note it needed two passes — a single patch increment from 3.0.81-alpha.8 lands on 3.0.81, which is already published on npm.

Reminder for the release: these packages require react-native-nitro-modules ≥ 0.35 in the app, so app-monorepo x must not pick up 3.0.82 without the nitro bump (app-monorepo PR #12875).

When JS sanitizes an edit back to the same string, React re-sends only mostRecentEventCount (unchanged props are not re-sent), so the rejected characters used to stay displayed. Both platforms now cache the last requested JS text — even when the update is rejected as stale — and the count setter reapplies it once the acknowledgement catches up. TextUpdateEventCounter.acknowledge() owns the transition and is unit-tested (10/10 via testDebugUnitTest).

- Bump the example's react-native-mmkv to 4.2.0: 4.1.x ships pre-0.35 codegen and fails Android Kotlin compilation against the 0.35 runtime (same reason the app upgraded). - Refresh the iOS Podfile.lock: mmkv 4.2.0 moves MMKVCore to 2.3.0, which also satisfies bundle-update's MMKV ~> 2.2. - Adopt the mostRecentEventCount protocol on the controlled AutoSizeInput examples, mirroring the app's wrapper. Verified on the emulator: rapid input (adb input text) previously lost characters to the inherent uncounted controlled-echo race; with the counter every character is retained. The remaining uncontrolled examples still cover the no-counter path.

weatherstar · 2026-08-14T03:53:35Z

Example app verified on both platforms against this branch (per huanming's request), commit a86ead1:

Android (emulator, Medium_Phone_API_36.0): :app:assembleDebug builds all 35 modules across 4 ABIs — BUILD SUCCESSFUL. App launches, JS loads (Running "example"), the Native Modules Test Suite list renders, and the Auto Size Input page instantiates its hybrid views and accepts typing with no crashes.

iOS (iPhone Air simulator, iOS 26.0.1): pod install + xcodebuild — BUILD SUCCEEDED, app installs, launches, and renders the same list.

Fixes needed to get there (included in a86ead1):

example's react-native-mmkv 4.1.x → 4.2.0 (4.1.x ships pre-0.35 codegen; compileDebugKotlin failed on updateNative), plus the resulting Podfile.lock refresh (MMKVCore 2.2.4 → 2.3.0, still satisfies bundle-update's MMKV ~> 2.2).
Adopted the mostRecentEventCount protocol on the controlled AutoSizeInput examples (mirrors the app wrapper). Empirically demonstrated on the emulator: rapid adb input text lost characters through the inherent uncounted controlled-echo race, and retains every character with the counter — a live integration check of the protocol discussed in the review threads. The uncontrolled examples still cover the no-counter path.

Setup note for anyone building the example from a fresh clone: run the workspace prepare builds first (yarn workspaces foreach --all --exclude '@onekeyfe/app-modules' --exclude '@onekeyfe/app-modules-example' run prepare) — Metro resolves the packages' lib/ output, which isn't generated by yarn install.

JS supplies mostRecentEventCount as a Double. On iOS, Int(_:) traps on NaN/infinity/out-of-range and would kill the process while applying a text update; validate via Int(exactly:) and fall back to uncounted. On Android, Double.toInt() coerces NaN to 0, which would silently opt the caller into filtering with a zero acknowledgement; filter non-finite values to null for the same uncounted fallback.

A fractional or finite out-of-range Double diverged: Android truncated or clamped (1.6 -> 1, stale) while iOS rounded (1.6 -> 2, current), so the same prop value could reject controlled text on one platform and apply it on the other. Valid acknowledgements are now exact, non-negative values in the Android Int range on both platforms — everything else degrades to uncounted. The rule lives in TextUpdateEventCounter.sanitizeAcknowledgement with unit coverage.

weatherstar added 2 commits August 14, 2026 10:36