feat(MSDK-3095): Added cursor AI rules#187
Conversation
|
CodeAnt AI is reviewing your PR. Thanks for using CodeAnt! 🎉We're free for open-source projects. if you're enjoying it, help us grow by sharing. Share on X · |
Review Summary by QodoAdd Cursor AI rules and configuration for project guidance
WalkthroughsDescription• Added comprehensive Cursor AI rules for project guidance • Created platform-specific rules for Android, iOS, and React Native • Established CI/CD, testing, and security best practices documentation • Added Cursor ignore configuration files for optimal indexing Diagramflowchart LR
A["Cursor Rules"] --> B["Project Overview"]
A --> C["Platform Rules"]
C --> D["Android Native"]
C --> E["iOS Native"]
C --> F["React Native"]
A --> G["Development Guides"]
G --> H["TypeScript Conventions"]
G --> I["Testing"]
G --> J["CI/CD & Security"]
A --> K["Cursor Config"]
K --> L[".cursorignore"]
K --> M[".cursorindexingignore"]
File Changes1. .cursor/rules/project-overview.mdc
|
Code Review by Qodo
1. Android minSdk wrong
|
📝 WalkthroughWalkthroughThis pull request introduces comprehensive Cursor AI rule documentation and configuration files for the Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
PR Summary: Adds sample/.ruby-version specifying Ruby 3.2.0; no cursor AI rules or other code changes included.
|
codeant-ai
bot
added
the
size:L
![pantoaibot[bot]](https://avatars.githubusercontent.com/in/934356?s=60&v=4){kind=small}
| @@ -0,0 +1 @@ | |||
| 3.2.0 | |||
There was a problem hiding this comment.
[NITPICK] Remove the leading whitespace so the file contains the Ruby version token exactly (e.g. "3.2.0"). Many Ruby version managers (rbenv, chruby, asdf) expect the file to contain the version string without surrounding spaces.
3.2.0
|
Reviewed up to commit:01567a06cef9181c86bc191a938b7190794992f7 Additional SuggestionOthers- Confirm this Ruby version is compatible with the sample project's native tooling (CocoaPods, fastlane, bundler) and with CI images. If you rely on a Gemfile/Gemfile.lock, ensure the Ruby version here matches any Ruby version specified there or document how contributors should select the Ruby version (rbenv/chruby/asdf). Consider adding the same .ruby-version at the repository root if CI and other parts of the repo need the same Ruby runtime. |
![codeant-ai[bot]](https://avatars.githubusercontent.com/in/646884?s=60&v=4){kind=small}
|
|
||
| ## Build | ||
|
|
||
| - Minimum iOS deployment target: 16.0. |
There was a problem hiding this comment.
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.| - 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.
Nitpicks 🔍
|
|
CodeAnt AI finished reviewing your PR. |
![qodo-code-review[bot]](https://avatars.githubusercontent.com/in/484649?s=60&v=4){kind=small}
|
|
||
| ## Build | ||
|
|
||
| - Min SDK: 26 (Android 8.0). |
There was a problem hiding this comment.
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
|
|
||
| ## Build | ||
|
|
||
| - Minimum iOS deployment target: 16.0. |
There was a problem hiding this comment.
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
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 4
🧹 Nitpick comments (1)
.cursorindexingignore (1)
35-37: Narrow indexing exclusions for core build/tooling files.
scripts/and Android Gradle config files are core project inputs, not generated artifacts. Ignoring them can reduce rule quality and produce weaker AI suggestions around build/test workflows.Suggested diff
# === Script files (utility, not core logic) === -scripts/ -sample/scripts/ +# Keep scripts indexable (used by CI/conventions) +# scripts/ +# sample/scripts/ # === Android generated === -android/build.gradle.kts -android/settings.gradle.kts -android/gradle.properties +# Keep root Android Gradle config indexable +# android/build.gradle.kts +# android/settings.gradle.kts +# android/gradle.propertiesAlso applies to: 46-48
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.cursorindexingignore around lines 35 - 37, The .cursorindexingignore currently excludes broad directories "scripts/" and "sample/scripts/" which hides core build/tooling files; update the ignore rules to narrow the scope (for example replace "scripts/" and "sample/scripts/" with more specific generated-artifact patterns such as "scripts/generated/" or "sample/scripts/generated/" or explicit filenames that are truly generated) or remove those lines entirely so Android Gradle config and other build scripts remain indexed; search for the exact strings "scripts/" and "sample/scripts/" in the .cursorindexingignore and apply the narrower patterns or deletion.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In @.cursor/rules/ci-github-actions.mdc:
- 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.
In @.cursor/rules/security-snyk.mdc:
- 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.
In @.cursor/rules/testing.mdc:
- Around line 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.
In @.cursor/rules/typescript-conventions.mdc:
- Around line 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).
---
Nitpick comments:
In @.cursorindexingignore:
- Around line 35-37: The .cursorindexingignore currently excludes broad
directories "scripts/" and "sample/scripts/" which hides core build/tooling
files; update the ignore rules to narrow the scope (for example replace
"scripts/" and "sample/scripts/" with more specific generated-artifact patterns
such as "scripts/generated/" or "sample/scripts/generated/" or explicit
filenames that are truly generated) or remove those lines entirely so Android
Gradle config and other build scripts remain indexed; search for the exact
strings "scripts/" and "sample/scripts/" in the .cursorindexingignore and apply
the narrower patterns or deletion.
ℹ️ Review info
Configuration used: defaults
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
sample/Gemfile.lockis excluded by!**/*.lock
📒 Files selected for processing (11)
.cursor/rules/android-native.mdc.cursor/rules/ci-github-actions.mdc.cursor/rules/ios-native.mdc.cursor/rules/project-overview.mdc.cursor/rules/react-native.mdc.cursor/rules/security-snyk.mdc.cursor/rules/testing.mdc.cursor/rules/typescript-conventions.mdc.cursorignore.cursorindexingignoresample/.ruby-version
| ## 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. |
There was a problem hiding this comment.
🧩 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):
- 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] - 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
- GitHub Docs – “Using immutable releases and tags…” (explains major tags like
v1and how tags can be force-moved) [1] - Mozilla GitHub workflow security guidance (recommends avoiding mutable tags like
@v1) [2] - GitHub Well-Architected – Actions security: pin to immutable refs (commit SHA recommended; “immutable tags” may be optional/disable-able) [3]
- GitHub Docs – immutable releases concept for unchangeable versions [1]
- 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.
| - 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.
| ## 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. |
There was a problem hiding this comment.
🧩 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 within1.2.x) [1]~1.2⇒>=1.2.0 <1.3.0(same as1.2.x) [1]~1⇒>=1.0.0 <2.0.0(same as1.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 major1) [1]^0.2.3⇒>=0.2.3 <0.3.0(only patch updates within minor0.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 samex.y.*). [1] - Use
^when you want minor+patch updates for1.0.0+, but more restrictive behavior in0.x(since0is 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.
| - Unit tests: `android/src/test/`. | ||
| - Instrumented tests: `android/src/androidTest/`. | ||
| - Run via `./gradlew :react-native-usercentrics:test` from `sample/android/`. | ||
|
|
There was a problem hiding this comment.
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.
| - 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.
| - The TurboModule spec lives in `src/fabric/NativeUsercentricsModule.ts`. | ||
| - It uses `TurboModuleRegistry` and `codegenNativeComponent`. | ||
| - Codegen config is in `package.json` under `codegenConfig`. |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
cat -n .cursor/rules/typescript-conventions.mdc | head -40Repository: Usercentrics/react-native-sdk
Length of output: 1530
🏁 Script executed:
rg -n 'TurboModuleRegistry|codegenNativeComponent|codegenNativeCommands' --type-list | head -5Repository: Usercentrics/react-native-sdk
Length of output: 462
🏁 Script executed:
fd -e ts -e tsx | xargs rg -l 'TurboModuleRegistry|codegenNativeComponent' | head -10Repository: 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)
codegenNativeComponentis for exposing native UI views to JS as a Fabric native component (props + events mapped to a nativeViewManager/component view). (reactnative.dev)
-
JS “spec” shape / API surface
- TurboModule spec: you define an interface that extends
TurboModuleand you typically export it viaTurboModuleRegistry.getEnforcing<Spec>(...). (reactnative.dev) - Native component spec: you define a props interface (usually extending
ViewProps), and exportcodegenNativeComponent<Props>('NativeName')(often cast toHostComponent<Props>). (reactnative.dev)
- TurboModule spec: you define an interface that extends
-
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)
- TurboModule spec files must be prefixed with
-
Codegen configuration difference
- In
codegenConfig, you generally settype: "modules"for TurboModules andtype: "components"for Fabric components (or"all"for both). (reactnative.dev)
- In
Citations:
- 1: https://reactnative.dev/docs/turbo-native-modules-introduction?utm_source=openai
- 2: https://reactnative.dev/docs/0.76/fabric-native-components-introduction?utm_source=openai
- 3: https://reactnative.dev/docs/turbo-native-modules-introduction?utm_source=openai
- 4: https://reactnative.dev/docs/0.76/fabric-native-components-introduction?utm_source=openai
- 5: https://reactnative.dev/docs/0.76/the-new-architecture/using-codegen?utm_source=openai
- 6: https://reactnative.dev/docs/0.76/the-new-architecture/using-codegen?utm_source=openai
- 7: https://reactnative.dev/docs/0.82/the-new-architecture/using-codegen?utm_source=openai
🏁 Script executed:
cat -n src/fabric/NativeUsercentricsModule.tsRepository: 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).
|
|
||
| ## Build | ||
|
|
||
| - Min SDK: 26 (Android 8.0). |
There was a problem hiding this comment.
our min sdk is 24 or 21 in legace, I guess we need to modify this
|
|
||
| ## Build | ||
|
|
||
| - Minimum iOS deployment target: 16.0. |
There was a problem hiding this comment.
same here, our deployment target is on iOS 11
2 participants
User description
Created multiple cursor rules for them to be used as a first basis
CodeAnt-AI Description
Add repository conventions, CI guidance, and editor indexing ignores for contributors
What Changed
Impact
✅ Clearer native contribution guidelines✅ Fewer CI surprises from mismatched local setups✅ Fewer accidental commits of build artifacts and secrets💡 Usage Guide
Checking Your Pull Request
Every time you make a pull request, our system automatically looks through it. We check for security issues, mistakes in how you're setting up your infrastructure, and common code problems. We do this to make sure your changes are solid and won't cause any trouble later.
Talking to CodeAnt AI
Got a question or need a hand with something in your pull request? You can easily get in touch with CodeAnt AI right here. Just type the following in a comment on your pull request, and replace "Your question here" with whatever you want to ask:
This lets you have a chat with CodeAnt AI about your pull request, making it easier to understand and improve your code.
Example
Preserve Org Learnings with CodeAnt
You can record team preferences so CodeAnt AI applies them in future reviews. Reply directly to the specific CodeAnt AI suggestion (in the same thread) and replace "Your feedback here" with your input:
This helps CodeAnt AI learn and adapt to your team's coding style and standards.
Example
Retrigger review
Ask CodeAnt AI to review the PR again, by typing:
Check Your Repository Health
To analyze the health of your code repository, visit our dashboard at https://app.codeant.ai. This tool helps you identify potential issues and areas for improvement in your codebase, ensuring your repository maintains high standards of code health.
Summary by CodeRabbit
Release Notes