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"
Copy link

Choose a reason for hiding this comment

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

Suggestion: The rule describes JNI/C++ conventions, but its globs only match Kotlin/Java/Gradle files, so edits in android/src/main/jni/** will not receive this rule. Expand the glob to include C/C++ JNI files so the documented constraints are actually enforced where they matter. [logic error]

Severity Level: Major ⚠️
- ⚠️ JNI edits miss documented "do not hand-edit" guidance.
- ⚠️ Android-native conventions apply inconsistently across native source types.
- ⚠️ Cursor assistance may suggest changes violating JNI workflow.
Suggested change
globs: "android/**/*.kt,android/**/*.kts,android/**/*.java"
globs: "android/**/*.kt,android/**/*.kts,android/**/*.java,android/src/main/jni/**/*.cpp,android/src/main/jni/**/*.c,android/src/main/jni/**/*.cc,android/src/main/jni/**/*.cxx,android/src/main/jni/**/*.h,android/src/main/jni/**/*.hpp"
Steps of Reproduction ✅
1. Open `.cursor/rules/android-native.mdc` and confirm the rule scope at line 3 only
includes `android/**/*.kt,android/**/*.kts,android/**/*.java`.

2. In the same rule file, confirm JNI-specific constraints are documented at lines 12 and
20 (`src/main/jni/` structure and "do not hand-edit" guidance).

3. Open an actual JNI file that exists in this repo,
`android/src/main/jni/RNUsercentricsModule.cpp` (lines 1–18), which is outside the
configured glob extensions.

4. Observe that this Android-native rule does not match/apply to that `.cpp` file, so
JNI-specific guidance from `.cursor/rules/android-native.mdc` is not surfaced when editing
JNI sources.
Prompt for AI Agent 🤖
This is a comment left during a code review.

**Path:** .cursor/rules/android-native.mdc
**Line:** 3:3
**Comment:**
	*Logic Error: The rule describes JNI/C++ conventions, but its `globs` only match Kotlin/Java/Gradle files, so edits in `android/src/main/jni/**` will not receive this rule. Expand the glob to include C/C++ JNI files so the documented constraints are actually enforced where they matter.

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.
👍 | 👎

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: 24 (Android 7.0).
- 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`.
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 Android CI command does not match the real workflow, so contributors following this rule will run the wrong task and miss the actual coverage/reporting pipeline behavior used in CI. [logic error]

Severity Level: Major ⚠️
- ⚠️ Android contributor guidance mismatches real CI execution.
- ⚠️ Local validation misses Kover coverage-report generation.
- ⚠️ Debugging CI failures becomes slower and confusing.
Suggested change
- Java 17, Gradle 8.13, `./gradlew :react-native-usercentrics:test`.
- Java 17, Gradle 8.13, `./gradlew :react-native-usercentrics:koverXmlReport :react-native-usercentrics:koverHtmlReport`.
Steps of Reproduction ✅
1. Open contributor rule `.cursor/rules/ci-github-actions.mdc:24-27`; it instructs Android
CI command `./gradlew :react-native-usercentrics:test`.

2. Trace real CI path in `.github/workflows/ci.yml:131-163`; `test-android` executes
`./gradlew :react-native-usercentrics:koverXmlReport
:react-native-usercentrics:koverHtmlReport`.

3. Note downstream dependency at `.github/workflows/ci.yml:165-170`; artifact upload
expects Kover output directory `android/build/reports/kover/`.

4. A contributor following the rule command locally will run a different Gradle target
than CI, so local validation diverges from actual CI behavior.
Prompt for AI Agent 🤖
This is a comment left during a code review.

**Path:** .cursor/rules/ci-github-actions.mdc
**Line:** 26:26
**Comment:**
	*Logic Error: The documented Android CI command does not match the real workflow, so contributors following this rule will run the wrong task and miss the actual coverage/reporting pipeline behavior used in CI.

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.
👍 | 👎


## Conventions

- Always use `--frozen-lockfile` (yarn) or `npm ci` (npm) for deterministic installs.
- Major-version tags (`@v1`, `@v2`, `@v4`) are mutable — maintainers can move them. They are acceptable for convenience on non-critical actions, but use full commit SHA pins (immutable) for security-sensitive actions (e.g., `actions/checkout@<full-sha>`).
- 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.
Copy link

Choose a reason for hiding this comment

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

Suggestion: This line states that Snyk scanning runs in CI, but there is no Snyk step in the current workflows, which creates a false security assumption and can allow vulnerabilities to slip through unnoticed. [security]

Severity Level: Critical 🚨
- ❌ Security guidance asserts non-existent CI vulnerability gate.
- ⚠️ Contributors may skip adding actual Snyk workflow step.
- ⚠️ Vulnerable dependencies can pass CI unchecked.
Suggested change
- Snyk scanning runs in the pipeline — ensure no new critical/high vulnerabilities are introduced.
- Snyk scanning is not currently configured in the existing GitHub workflows; add and enforce a Snyk CI step before relying on this check.
Steps of Reproduction ✅
1. Read `.cursor/rules/ci-github-actions.mdc:33`; it states Snyk scanning already runs in
pipeline.

2. Verify actual workflows list from `.github/workflows/` contains only `ci.yml` and
`release.yml`.

3. Inspect `.github/workflows/ci.yml:1-170` and `.github/workflows/release.yml:1-23`;
there is no `snyk` command/action/step.

4. Security assumption in the rule is therefore false for current CI, so contributors may
believe vulnerability gating exists when it does not.
Prompt for AI Agent 🤖
This is a comment left during a code review.

**Path:** .cursor/rules/ci-github-actions.mdc
**Line:** 33:33
**Comment:**
	*Security: This line states that Snyk scanning runs in CI, but there is no Snyk step in the current workflows, which creates a false security assumption and can allow vulnerabilities to slip through unnoticed.

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.
👍 | 👎

- 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: 11.0.
- CocoaPods managed via Bundler (`bundle exec pod install`).
Copy link

Choose a reason for hiding this comment

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

Suggestion: The Bundler command is documented without the required working directory, but this repository's Gemfile is under sample/, not the repo root. Running bundle exec pod install from the wrong location will fail, so the rule should explicitly scope the command to sample/ios. [possible bug]

Severity Level: Major ⚠️
- ⚠️ iOS setup docs can fail for contributors.
- ⚠️ CocoaPods install flow becomes inconsistent with CI.
- ⚠️ Native development onboarding slows due to command errors.
Suggested change
- CocoaPods managed via Bundler (`bundle exec pod install`).
- CocoaPods managed via Bundler from `sample/ios/` (`cd sample/ios && bundle exec pod install`).
Steps of Reproduction ✅
1. Open `.cursor/rules/ios-native.mdc:27`; it documents `bundle exec pod install` without
a working directory.

2. Verify repository Ruby setup: only `sample/Gemfile` exists
(`/workspace/react-native-sdk/sample/Gemfile:1`), no root Gemfile.

3. From repo root (`/workspace/react-native-sdk`), run the documented command exactly;
Bundler resolves Gemfile from current/parent path and cannot use project gems.

4. Confirm intended path from CI: `.github/workflows/ci.yml:84-94` runs `bundle install`
in `./sample` and `bundle exec pod install` in `./sample/ios`, showing the command is
directory-scoped in real usage.
Prompt for AI Agent 🤖
This is a comment left during a code review.

**Path:** .cursor/rules/ios-native.mdc
**Line:** 27:27
**Comment:**
	*Possible Bug: The Bundler command is documented without the required working directory, but this repository's `Gemfile` is under `sample/`, not the repo root. Running `bundle exec pod install` from the wrong location will fail, so the rule should explicitly scope the command to `sample/ios`.

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.
👍 | 👎

- 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. Use `^` ranges (minor + patch updates within the same major, e.g. `^1.2.3` => `>=1.2.3 <2.0.0`) or `~` ranges (patch-only updates within the same minor, e.g. `~1.2.3` => `>=1.2.3 <1.3.0`) depending on risk tolerance.
- 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.
32 changes: 32 additions & 0 deletions .cursor/rules/testing.mdc
Original file line number Diff line number Diff line change
@@ -0,0 +1,32 @@
---
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`.
Copy link

Choose a reason for hiding this comment

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

Suggestion: The iOS test command is incomplete and will fail if copied as-is because xcodebuild test requires at least a scheme and destination. Align this line with the actual CI invocation by including -workspace, -scheme, and simulator destination arguments so contributors can run tests successfully. [logic error]

Severity Level: Major ⚠️
- ⚠️ Cursor rule conflicts with CI iOS test invocation.
- ⚠️ Contributors may hit failing local iOS test runs.
- ❌ iOS test setup requires manual command troubleshooting.
Suggested change
- Run via `xcodebuild test` against `sample.xcworkspace`.
- Run via `xcodebuild -workspace sample.xcworkspace -scheme sample -destination 'platform=iOS Simulator,OS=latest,name=iPhone 16 Pro' test`.
Steps of Reproduction ✅
1. Open `.cursor/rules/testing.mdc:20`; copy the documented iOS command `xcodebuild test`.

2. From `sample/ios` (CI uses this working directory at `.github/workflows/ci.yml:101`),
execute that copied command.

3. Compare with the real CI invocation at `.github/workflows/ci.yml:104-111`, which
explicitly passes `-workspace sample.xcworkspace`, `-scheme "sample"`, and simulator
`-destination`.

4. Because the rule omits those targeting flags, contributors/Cursor-generated
instructions can run with missing context and commonly fail or run unintended targets,
unlike CI's deterministic command.
Prompt for AI Agent 🤖
This is a comment left during a code review.

**Path:** .cursor/rules/testing.mdc
**Line:** 20:20
**Comment:**
	*Logic Error: The iOS test command is incomplete and will fail if copied as-is because `xcodebuild test` requires at least a scheme and destination. Align this line with the actual CI invocation by including `-workspace`, `-scheme`, and simulator destination arguments so contributors can run tests successfully.

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.
👍 | 👎


## Android (JUnit + MockK)

- Unit tests: `android/src/test/`. Run via `./gradlew :react-native-usercentrics:test` from `sample/android/`.
- Instrumented tests: `android/src/androidTest/`. Run via `./gradlew :react-native-usercentrics:connectedAndroidTest` (requires a connected device or emulator).

## 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
Loading