Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
27 changes: 27 additions & 0 deletions .cursor/rules/android-native.mdc
Original file line number Diff line number Diff line change
@@ -0,0 +1,27 @@
---
description: Android native module conventions (Kotlin, Gradle)
globs: "android/**/*.kt,android/**/*.kts,android/**/*.java"
alwaysApply: false
---

# Android Native Module

## Structure

- `src/main/java/com/usercentrics/reactnative/` — Kotlin module, package, and bridge classes.
- `src/main/jni/` — C++ JNI bindings for Fabric/TurboModules (auto-generated via codegen).
- `src/test/` — JUnit + MockK unit tests.
- `src/androidTest/` — Instrumented tests.

## Conventions

- Kotlin for all new code. No Java unless maintaining legacy.
- Gradle Kotlin DSL (`build.gradle.kts`).
- JNI/C++ files under `src/main/jni/` are generated by `scripts/generate-codegen-jni.js` — do not hand-edit.

## Build

- Min SDK: 26 (Android 8.0).

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Action required

1. Android minsdk wrong 🐞 Bug ✓ Correctness

The new Android Cursor rule claims Min SDK 26, but the actual Android library module is configured
with minSdk 24 (and legacy gradle uses 21). This mismatch can mislead contributors/AI into using
APIs unavailable on supported devices or proposing unnecessary minSdk bumps.
Agent Prompt
## Issue description
The Cursor rule `.cursor/rules/android-native.mdc` documents an Android Min SDK of 26, but the repository’s Android library module currently uses `minSdk = 24`. This mismatch can cause AI-assisted changes (or contributors following the rule) to use APIs not available on supported devices or propose unnecessary breaking minSdk increases.

## Issue Context
Source of truth is the Gradle configuration in `android/build.gradle.kts`.

## Fix Focus Areas
- .cursor/rules/android-native.mdc[22-27]
- android/build.gradle.kts[21-29]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

our min sdk is 24 or 21 in legace, I guess we need to modify this

- Java 17 for compilation.
- Gradle 8.13.
- Tests run via `./gradlew :react-native-usercentrics:test` from `sample/android/`.
34 changes: 34 additions & 0 deletions .cursor/rules/ci-github-actions.mdc
Original file line number Diff line number Diff line change
@@ -0,0 +1,34 @@
---
description: CI/CD and GitHub Actions conventions
globs: '.github/**/*.yml,.github/**/*.yaml'
alwaysApply: false
---

# CI/CD — GitHub Actions

## Workflows

- **`ci.yml`** — Runs on PRs to `master`. Jobs: `test-rn`, `test-ios`, `test-android`.
- **`release.yml`** — Triggers on GitHub release creation. Publishes to npm.

## CI Jobs

### test-rn (Ubuntu)

- Node 20, `yarn install --frozen-lockfile`, `yarn compile`, `yarn test`, `assert_export.sh`.

### test-ios (macOS 14)

- Xcode 16.1, Ruby 3.2, CocoaPods via Bundler, `xcodebuild test` on iPhone 16 Pro simulator.

### test-android (macOS 14)

- Java 17, Gradle 8.13, `./gradlew :react-native-usercentrics:test`.

## Conventions

- Always use `--frozen-lockfile` (yarn) or `npm ci` (npm) for deterministic installs.
- Use pinned action versions (`@v1`, `@v2`, `@v4`) — prefer SHA pinning for security-critical actions.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟡 Minor

🧩 Analysis chain

🌐 Web query:

GitHub Actions @v1 @v2 major version tags mutable pinning security

💡 Result:

uses: owner/action@v1 / @v2 are Git tags (major-version “floating” tags). Tags are mutable in Git: the action maintainer (or an attacker who compromises the repo) can move v1 to a different commit (e.g., via force-updating the tag), so your workflow may run different code later without any change in your repo—a supply-chain risk. [1], [2]

Safer pinning options (recommended order):

  1. Pin to a full commit SHA (immutable): uses: actions/checkout@<40-char-sha> # vX.Y.Z—this ensures you always run exactly the reviewed code. GitHub’s guidance explicitly recommends SHA pinning to reduce the impact of compromised tags/branches. [3]
  2. Use an “immutable release/tag” only if the publisher has enabled immutable releases: GitHub supports making releases immutable (so the release’s Git tag/assets can’t be changed), but this depends on the action repository’s configuration. [1], [4]

Org/enterprise enforcement: GitHub Actions policies can enforce SHA pinning (workflows fail if an action isn’t pinned to a full SHA) and can also block specific actions/versions. [5]

Why major tags are popular anyway: @v1/@v2 are convenient for automatically receiving compatible updates, but that convenience is exactly what makes them risky if the tag is ever retargeted maliciously. [2], [3]

Sources

  1. GitHub Docs – “Using immutable releases and tags…” (explains major tags like v1 and how tags can be force-moved) [1]
  2. Mozilla GitHub workflow security guidance (recommends avoiding mutable tags like @v1) [2]
  3. GitHub Well-Architected – Actions security: pin to immutable refs (commit SHA recommended; “immutable tags” may be optional/disable-able) [3]
  4. GitHub Docs – immutable releases concept for unchangeable versions [1]
  5. GitHub Changelog (Aug 15, 2025) – policy supports blocking and enforcing SHA pinning [5]

🌐 Web query:

GitHub Actions official recommendation secure pinning third-party actions commit SHA

💡 Result:

GitHub’s official guidance for securing third-party GitHub Actions is to pin actions to a full-length commit SHA (instead of a moving tag like @v1/@v4). GitHub notes this is currently the only way to use an action as an immutable release, and recommends verifying the SHA comes from the action’s official repository (not a fork). [1]

GitHub has also reiterated this recommendation in policy/governance updates: GitHub recommends SHA pinning to reduce supply-chain risk, and admins can enforce “full commit SHA” pinning so workflows fail if an action isn’t pinned. [2]

Example:

- uses: actions/checkout@692973e3d937129bcbf40652eb9f2f61becf3332 # v4.1.7

[1]

Sources:
[1] GitHub Docs (Actions security guide: “Using third-party actions”)
[2] GitHub Changelog (Allowed actions policy: “Enforce SHA pinning”, Aug 15, 2025)


@vX tags are mutable, not immutable pins.

Line 31 conflates two distinct concepts: major version tags like @v4 are mutable Git references that can be force-updated by maintainers or attackers. Only commit SHAs provide immutability. Clarify the guidance to distinguish them.

Proposed wording
- Use pinned action versions (`@v1`, `@v2`, `@v4`) — prefer SHA pinning for security-critical actions.
+ Use major version tags (`@v1`, `@v2`, `@v4`) for readability, but pin to full commit SHAs for security-critical actions (or all actions when possible).
📝 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.

Suggested change
- Use pinned action versions (`@v1`, `@v2`, `@v4`) — prefer SHA pinning for security-critical actions.
- Use major version tags (`@v1`, `@v2`, `@v4`) for readability, but pin to full commit SHAs for security-critical actions (or all actions when possible).
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In @.cursor/rules/ci-github-actions.mdc at line 31, The guidance text currently
conflates major-version tags with immutable pins; update the wording around the
`@v1`, `@v2`, `@v4` examples to state that these are mutable tags (they can be
moved by maintainers) and therefore are not equivalent to commit SHA pins, and
explicitly recommend using full commit SHAs for security-critical actions while
noting that major-version tags are acceptable for convenience/non-critical uses;
reference the `@v1/@v2/@v4` tokens and recommend “use full commit SHA
(immutable) for security-sensitive actions” as the replacement phrasing.

- Do not store secrets in workflow files. Use GitHub Secrets and reference via `${{ secrets.NAME }}`.
- Snyk scanning runs in the pipeline — ensure no new critical/high vulnerabilities are introduced.
- Keep CI fast: run JS tests first (`test-rn`), gate native tests behind it with `needs: test-rn`.
28 changes: 28 additions & 0 deletions .cursor/rules/ios-native.mdc
Original file line number Diff line number Diff line change
@@ -0,0 +1,28 @@
---
description: iOS native module conventions (Swift, ObjC++)
globs: "ios/**/*.swift,ios/**/*.mm,ios/**/*.h"
alwaysApply: false
---

# iOS Native Module

## Structure

- `RNUsercentricsModule.swift` — Main module class, bridge methods.
- `RNUsercentricsModule.mm` — ObjC++ bridge for TurboModule registration.
- `Manager/` — Swift helpers/managers that wrap the native Usercentrics iOS SDK.
- `Extensions/` — Swift extensions for type conversions (NSDictionary <-> Swift models).
- `Errors/` — Typed error definitions for the bridge layer.

## Conventions

- Use Swift for all new logic. ObjC++ only for required bridge glue.
- Bridging header: `RNUsercentricsModule-Bridging-Header.h`.
- Codegen spec header: `RNUsercentricsModuleSpec.h` (auto-generated, do not edit).
- The podspec is `react-native-usercentrics.podspec` at the repo root.

## Build

- Minimum iOS deployment target: 16.0.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggestion: The documented minimum iOS deployment target (16.0) conflicts with the actual podspec configuration, which declares iOS 11.0; this mismatch can mislead tools and developers (including Cursor itself) into using APIs that only exist on iOS 16+, causing runtime crashes or build failures for consumers targeting iOS 11–15. [logic error]

Severity Level: Major ⚠️
- ⚠️ Cursor rules misstate supported iOS version for native modules.
- ⚠️ Developers may introduce iOS16-only APIs into iOS11 projects.
Suggested change
- Minimum iOS deployment target: 16.0.
- Minimum iOS deployment target: 11.0.
Steps of Reproduction ✅
1. Open the podspec at `react-native-usercentrics.podspec:13` (in
`/workspace/react-native-sdk/react-native-usercentrics.podspec`) and observe `s.platform =
:ios, "11.0"`, which declares the library's minimum iOS version as 11.0.

2. Open the Cursor rules file at `.cursor/rules/ios-native.mdc:26` and observe the
documentation line `- Minimum iOS deployment target: 16.0.` indicating a minimum iOS
version of 16.0 for the same native module.

3. Compare these two configuration sources and note the direct contradiction: tooling and
developers reading `.cursor/rules/ios-native.mdc` will believe the minimum supported iOS
version is 16.0, while the actual build configuration via CocoaPods allows iOS 11.0.

4. In a real development workflow, a developer or AI assistant (Cursor) relying on
`.cursor/rules/ios-native.mdc` to guide native code changes for `ios/**/*.swift` and
`ios/**/*.mm` files can reasonably assume iOS 16.0 APIs are safe to use, even though
consumers building against the podspec's iOS 11.0 target would encounter compile-time or
runtime issues when those newer APIs are used on older devices.
Prompt for AI Agent 🤖
This is a comment left during a code review.

**Path:** .cursor/rules/ios-native.mdc
**Line:** 26:26
**Comment:**
	*Logic Error: The documented minimum iOS deployment target (16.0) conflicts with the actual podspec configuration, which declares iOS 11.0; this mismatch can mislead tools and developers (including Cursor itself) into using APIs that only exist on iOS 16+, causing runtime crashes or build failures for consumers targeting iOS 11–15.

Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
👍 | 👎

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Action required

2. Ios target wrong 🐞 Bug ✓ Correctness

The new iOS Cursor rule claims a minimum iOS deployment target of 16.0, but the podspec and Xcode
project are configured for iOS 11.0. This can lead to AI/contributor changes using iOS APIs
unavailable on supported OS versions.
Agent Prompt
## Issue description
The Cursor rule `.cursor/rules/ios-native.mdc` states the minimum iOS deployment target is 16.0, but the repo’s podspec and Xcode project are configured for iOS 11.0. This mismatch can mislead AI-assisted edits to use APIs unavailable on supported targets.

## Issue Context
Source of truth is `react-native-usercentrics.podspec` (`s.platform = :ios, "11.0"`).

## Fix Focus Areas
- .cursor/rules/ios-native.mdc[24-28]
- react-native-usercentrics.podspec[11-14]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

same here, our deployment target is on iOS 11

- CocoaPods managed via Bundler (`bundle exec pod install`).
- Xcode tests live in `sample/ios/sampleTests/` (XCTest, Swift).
31 changes: 31 additions & 0 deletions .cursor/rules/project-overview.mdc
Original file line number Diff line number Diff line change
@@ -0,0 +1,31 @@
---
description: Project overview and architecture for @usercentrics/react-native-sdk
alwaysApply: true
---

# Project Overview

This is `@usercentrics/react-native-sdk` — a React Native bridge for the Usercentrics Consent Management Platform (CMP).

## Architecture

- **`src/`** — TypeScript SDK source. Models, Fabric TurboModule spec, and the main `Usercentrics` API.
- **`android/`** — Kotlin native module with C++ JNI bindings (Fabric/TurboModules).
- **`ios/`** — Swift native module with ObjC++ bridge (Fabric/TurboModules).
- **`sample/`** — Primary sample app (RN 0.81, used in CI).
- **`example/`** — Secondary example app (RN 0.78).
- **`legacy-sample/`** — Legacy sample (older RN, Java/Flow). Do not modify unless explicitly asked.

## Key Conventions

- Package manager: **yarn 1.x** (classic). Use `yarn install --frozen-lockfile` in CI.
- Compiled output goes to `lib/` via `tsc`. Entry point: `lib/index.js`.
- React Native Codegen is used for Fabric/TurboModule specs in `src/fabric/`.
- The SDK has zero runtime dependencies — only peer deps on `react` and `react-native`.
- All public types/APIs must be re-exported from `src/index.tsx` (enforced by `scripts/assert_export.sh`).

## Formatting

- Prettier: single quotes, no semicolons, JSX single quotes.
- ESLint: `@react-native-community` config + `simple-import-sort` plugin.
- Imports must be sorted via `simple-import-sort`.
30 changes: 30 additions & 0 deletions .cursor/rules/react-native.mdc
Original file line number Diff line number Diff line change
@@ -0,0 +1,30 @@
---
description: React Native patterns for SDK and sample apps
globs: "**/*.tsx,**/*.jsx"
alwaysApply: false
---

# React Native Patterns

## SDK Bridge Layer

- The SDK exposes a singleton `Usercentrics` object (not a React component).
- Native communication goes through `NativeModules` / TurboModules, not direct native calls.
- All native method signatures must match across TS spec, Kotlin, and Swift.

## Sample App

- The sample app in `sample/` is the canonical integration test app.
- Metro config uses `watchFolders` to include the parent SDK directory.
- `react-native.config.js` in sample links back to the parent SDK for auto-linking.

## Component Patterns

- Functional components only. No class components.
- Use React hooks for state and lifecycle.
- Keep screen components in a flat structure.

## Navigation

- The sample app uses React Navigation for screen routing.
- Screens: Home, CustomUI, CustomizationExamples, WebviewIntegration.
57 changes: 57 additions & 0 deletions .cursor/rules/security-snyk.mdc
Original file line number Diff line number Diff line change
@@ -0,0 +1,57 @@
---
description: Security best practices and Snyk compliance rules
alwaysApply: true
---

# Security & Snyk Compliance

Snyk runs in CI pipelines to scan for vulnerabilities. Follow these rules to avoid introducing issues.

## Dependency Security

- **Never** pin exact versions of transitive dependencies to work around vulnerabilities — fix at the source.
- Keep dependencies up to date. Prefer `^` ranges in `package.json` to allow patch updates.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟡 Minor

🧩 Analysis chain

🌐 Web query:

npm semver caret ^ tilde ~ version ranges documentation what updates allowed

💡 Result:

Tilde ~ ranges (npm)

~ lets npm install newer patch versions within the same minor (if a minor is specified). Examples:

  • ~1.2.3>=1.2.3 <1.3.0 (patch updates only within 1.2.x) [1]
  • ~1.2>=1.2.0 <1.3.0 (same as 1.2.x) [1]
  • ~1>=1.0.0 <2.0.0 (same as 1.x) [1]

Caret ^ ranges (npm)

^ lets npm install changes that don’t modify the left-most non-zero digit. Examples:

  • ^1.2.3>=1.2.3 <2.0.0 (minor + patch updates within major 1) [1]
  • ^0.2.3>=0.2.3 <0.3.0 (only patch updates within minor 0.2) [1]
  • ^0.0.3>=0.0.3 <0.0.4 (effectively pinned to that patch line) [1]

Rule of thumb

  • Use ~ when you want patch-only updates (stay on the same x.y.*). [1]
  • Use ^ when you want minor+patch updates for 1.0.0+, but more restrictive behavior in 0.x (since 0 is treated specially). [1]

Sources: npm semver range docs [1].


Correct semver guidance: ^ allows minor and patch updates, not patch-only.

Line 13 is misleading. In npm semver, ^ allows minor and patch updates within the same major version (e.g., ^1.2.3>=1.2.3 <2.0.0), not only patch updates. For patch-only updates, use ~ (e.g., ~1.2.3>=1.2.3 <1.3.0).

Update the text to clarify which operator allows which update types.

🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In @.cursor/rules/security-snyk.mdc at line 13, Update the guidance text that
currently states "Prefer `^` ranges in `package.json` to allow patch updates" to
correctly describe semver: explain that `^` allows minor and patch updates
within the same major version (e.g., `^1.2.3` => >=1.2.3 <2.0.0) and that `~`
allows patch-only updates within the same minor version (e.g., `~1.2.3` =>
>=1.2.3 <1.3.0`), replacing the incorrect sentence referencing the `^` operator;
ensure the revised line mentions both `^` and `~` operators and their respective
update scopes.

- Do not add dependencies unless strictly necessary. This SDK has **zero** runtime dependencies by design.
- When adding devDependencies, verify they don't have known critical/high CVEs (`npx snyk test` locally).
- Never commit lock files with known vulnerable dependency resolutions without a remediation plan.

## Secrets & Credentials

- **Never** hardcode API keys, tokens, secrets, or credentials in source code.
- Never commit `.env` files, `google-services.json`, keystores (`*.jks`, `*.keystore`), or private keys.
- Use environment variables for any sensitive configuration in CI/CD.
- If a secret is needed in a sample app, use a placeholder value and document the setup.

## Code Security (Snyk Code)

- Avoid `eval()`, `Function()` constructor, and dynamic code execution.
- Never use `dangerouslySetInnerHTML` without sanitization.
- Sanitize and validate all data crossing the native bridge boundary.
- Do not disable SSL/TLS certificate validation in any code.
- Avoid hardcoded IP addresses or URLs pointing to internal infrastructure.
- Use parameterized queries — never concatenate user input into commands or queries.

## Native Code Security

### iOS
- Do not disable App Transport Security (ATS) in production.
- Avoid storing sensitive data in `UserDefaults` — use Keychain for secrets.
- Do not log sensitive user data (PII, consent tokens) in release builds.

### Android
- Do not set `android:debuggable="true"` in release manifests.
- Do not set `android:allowBackup="true"` without encrypting backup data.
- Avoid using `MODE_WORLD_READABLE` or `MODE_WORLD_WRITEABLE` for file storage.
- Do not log sensitive data with `Log.d`/`Log.v` in release builds — use `Log.e` sparingly.
- Use `ProGuard`/`R8` for release builds to strip debug info.

## Open Source License Compliance

- Only add dependencies with licenses compatible with Apache 2.0 (this project's license).
- Snyk also checks license compliance. Avoid GPL-licensed dependencies.

## Supply Chain

- Always use `--frozen-lockfile` / `npm ci` in CI to ensure reproducible builds.
- Do not run arbitrary `postinstall` scripts from untrusted packages.
- Review new dependencies before adding them — check download counts, maintenance status, and known issues.
33 changes: 33 additions & 0 deletions .cursor/rules/testing.mdc
Original file line number Diff line number Diff line change
@@ -0,0 +1,33 @@
---
description: Testing conventions for the SDK
globs: "**/__tests__/**,**/*.test.*,**/sampleTests/**,**/src/test/**,**/src/androidTest/**"
alwaysApply: false
---

# Testing

## JavaScript / TypeScript (Jest)

- Tests live in `src/__tests__/`.
- Jest config is in `package.json` under the `jest` key (preset: `react-native`).
- Mock native modules in `src/__tests__/mocks.ts`.
- Run with `yarn test`.

## iOS (XCTest)

- Tests live in `sample/ios/sampleTests/`.
- Written in Swift, targeting the sample app scheme.
- Run via `xcodebuild test` against `sample.xcworkspace`.

## Android (JUnit + MockK)

- Unit tests: `android/src/test/`.
- Instrumented tests: `android/src/androidTest/`.
- Run via `./gradlew :react-native-usercentrics:test` from `sample/android/`.

Comment on lines +24 to +27
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟡 Minor

Android test commands are incomplete for stated scope.

You document both unit and instrumented tests, but only provide the unit-test command. Add an explicit instrumented-test command to avoid false confidence in coverage.

Suggested diff
 - Unit tests: `android/src/test/`.
 - Instrumented tests: `android/src/androidTest/`.
 - Run via `./gradlew :react-native-usercentrics:test` from `sample/android/`.
+- Run instrumented tests via `./gradlew :react-native-usercentrics:connectedAndroidTest` (or your CI equivalent) from `sample/android/`.
📝 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.

Suggested change
- Unit tests: `android/src/test/`.
- Instrumented tests: `android/src/androidTest/`.
- Run via `./gradlew :react-native-usercentrics:test` from `sample/android/`.
- Unit tests: `android/src/test/`.
- Instrumented tests: `android/src/androidTest/`.
- Run via `./gradlew :react-native-usercentrics:test` from `sample/android/`.
- Run instrumented tests via `./gradlew :react-native-usercentrics:connectedAndroidTest` (or your CI equivalent) from `sample/android/`.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In @.cursor/rules/testing.mdc around lines 24 - 27, The documentation lists unit
and instrumented tests but only provides the unit test command; add an explicit
instrumented-test command for clarity by appending the connected Android
instrumentation command (e.g., ./gradlew
:react-native-usercentrics:connectedAndroidTest) alongside the existing unit
test command (./gradlew :react-native-usercentrics:test), and optionally mention
assembleAndroidTest or installDebug and connectedAndroidTest for CI/use cases so
readers can run instrumented tests reliably.

## Guidelines

- Test the public API surface, not internal implementation details.
- Native bridge methods should have corresponding tests on both platforms.
- When adding a new public method to `Usercentrics`, add a Jest test and at minimum one native platform test.
- Keep mocks minimal — only mock the native module boundary.
36 changes: 36 additions & 0 deletions .cursor/rules/typescript-conventions.mdc
Original file line number Diff line number Diff line change
@@ -0,0 +1,36 @@
---
description: TypeScript conventions for the SDK source code
globs: src/**/*.ts,src/**/*.tsx
alwaysApply: false
---

# TypeScript Conventions

## Style

- Strict mode is enabled (`"strict": true` in tsconfig).
- Target: ES2018. Module: ESNext. Module resolution: Node.
- No semicolons, single quotes, JSX single quotes (Prettier enforced).

## Exports

- Every public type, enum, interface, and function **must** be re-exported from `src/index.tsx`.
- The CI script `scripts/assert_export.sh` will fail if exports are missing.

## Models

- Model files live in `src/models/`. One model concern per file.
- Use TypeScript `enum` for SDK enums (matching native SDK enums).
- Use `interface` for data structures returned from native side.

## Fabric / TurboModules

- The TurboModule spec lives in `src/fabric/NativeUsercentricsModule.ts`.
- It uses `TurboModuleRegistry` and `codegenNativeComponent`.
- Codegen config is in `package.json` under `codegenConfig`.
Comment on lines +28 to +30
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

🧩 Analysis chain

🏁 Script executed:

cat -n .cursor/rules/typescript-conventions.mdc | head -40

Repository: Usercentrics/react-native-sdk

Length of output: 1530


🏁 Script executed:

rg -n 'TurboModuleRegistry|codegenNativeComponent|codegenNativeCommands' --type-list | head -5

Repository: Usercentrics/react-native-sdk

Length of output: 462


🏁 Script executed:

fd -e ts -e tsx | xargs rg -l 'TurboModuleRegistry|codegenNativeComponent' | head -10

Repository: Usercentrics/react-native-sdk

Length of output: 137


🌐 Web query:

React Native TurboModule codegenNativeComponent API difference official documentation

💡 Result:

  • What they are for

    • TurboModules are for exposing imperative native APIs to JS (functions/constants) as a native module (e.g., storage, sensors). (reactnative.dev)
    • codegenNativeComponent is for exposing native UI views to JS as a Fabric native component (props + events mapped to a native ViewManager/component view). (reactnative.dev)
  • JS “spec” shape / API surface

    • TurboModule spec: you define an interface that extends TurboModule and you typically export it via TurboModuleRegistry.getEnforcing<Spec>(...). (reactnative.dev)
    • Native component spec: you define a props interface (usually extending ViewProps), and export codegenNativeComponent<Props>('NativeName') (often cast to HostComponent<Props>). (reactnative.dev)
  • Codegen detection conventions (important “difference” people hit)

    • TurboModule spec files must be prefixed with Native (example: NativeLocalStorage.ts). (reactnative.dev)
    • Fabric native component spec files must be suffixed with NativeComponent (example: WebViewNativeComponent.ts). (reactnative.dev)
  • Codegen configuration difference

    • In codegenConfig, you generally set type: "modules" for TurboModules and type: "components" for Fabric components (or "all" for both). (reactnative.dev)

Citations:


🏁 Script executed:

cat -n src/fabric/NativeUsercentricsModule.ts

Repository: Usercentrics/react-native-sdk

Length of output: 2195


🏁 Script executed:

cat -n package.json | grep -A 20 'codegenConfig'

Repository: Usercentrics/react-native-sdk

Length of output: 329


Line 29 incorrectly lists codegenNativeComponent as part of TurboModule setup.

codegenNativeComponent is a Fabric Native Component API for UI views. The actual implementation uses only TurboModuleRegistry. Remove codegenNativeComponent from this line to prevent misleading developers on correct TurboModule patterns.

🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In @.cursor/rules/typescript-conventions.mdc around lines 28 - 30, The
documentation incorrectly states that the TurboModule spec uses
codegenNativeComponent; update the sentence that currently lists both
TurboModuleRegistry and codegenNativeComponent to remove codegenNativeComponent
so it only references TurboModuleRegistry (keep reference to the TurboModule
spec file NativeUsercentricsModule.ts for context).

- Changes to the spec require regenerating JNI bindings (`npm run prepublishOnly`).

## Error Handling

- Native bridge calls can throw. Always handle errors from `NativeModules` calls.
- Use typed error objects rather than raw string checks.
113 changes: 113 additions & 0 deletions .cursorignore
Original file line number Diff line number Diff line change
@@ -0,0 +1,113 @@
# === Dependencies ===
node_modules/
sample/node_modules/
example/node_modules/
legacy-sample/node_modules/
jspm_packages/
web_modules/
bower_components/

# === Build outputs ===
lib/
**/build/
.gradle/
.gradle
buck-out/
.cxx/
.externalNativeBuild/
DerivedData/

# === iOS artifacts ===
**/Pods/
sample/vendor/bundle/
*.ipa
*.dSYM.zip
*.dSYM
xcuserdata/

# === Android artifacts ===
*.apk
*.aab
*.hprof
local.properties
captures/

# === Package archives ===
*.tgz
*.tar.gz
*.zip

# === IDE / Editor ===
.idea/
*.iml
.vscode-test
*.xccheckout
*.xcscmblueprint
*.xcuserstate

# === OS files ===
.DS_Store
._*
.AppleDouble
.LSOverride
Thumbs.db
.Spotlight-V100
.Trashes

# === Logs ===
*.log
npm-debug.log*
yarn-debug.log*
yarn-error.log*
lerna-debug.log*

# === Coverage / test output ===
coverage/
*.lcov
.nyc_output

# === Caches ===
.eslintcache
.stylelintcache
*.tsbuildinfo
.cache/
.parcel-cache
.rpt2_cache/
.rts2_cache_cjs/
.rts2_cache_es/
.rts2_cache_umd/
.metro-health-check*
.fusebox/

# === Secrets / environment ===
.env
.env.*
!.env.example
google-services.json
*.jks
*.keystore
!debug.keystore

# === Expo / Metro ===
.expo
__generated__

# === Yarn v2+ ===
.yarn/cache
.yarn/unplugged
.yarn/build-state.yml
.yarn/install-state.gz
.pnp.*

# === Buck ===
.buckconfig.local
.buckd/
.buckversion
.fakebuckversion

# === Misc generated ===
.docusaurus
.serverless/
.dynamodb/
.temp
report.[0-9]*.[0-9]*.[0-9]*.[0-9]*.json
Loading