chore: add coderabbit and cursor rules (#272)

## Summary by CodeRabbit

- **Documentation**
  - Added comprehensive documentation and configuration files outlining coding standards, best practices, and guidelines for TypeScript development, including naming conventions, error handling, property mutability, return types, and library installation.
  - Introduced rules for code structure, export practices, discriminated unions, enums, JSDoc usage, and more.
  - Provided clear examples and explanations to support consistent and maintainable code across the project.

- **Chores**
  - Added a configuration file to enable and configure various code quality and review tools, linters, and integrations for automated code analysis and workflow enhancements.

Author: mheob

.coderabbit.yaml

@@ -0,0 +1,144 @@
+language: en-US
+tone_instructions: ""
+early_access: false
+enable_free_tier: true
+reviews:
+  profile: chill
+  request_changes_workflow: true
+  high_level_summary: true
+  high_level_summary_placeholder: "@coderabbitai summary"
+  high_level_summary_in_walkthrough: false
+  auto_title_placeholder: "@coderabbitai"
+  auto_title_instructions: ""
+  review_status: true
+  commit_status: true
+  fail_commit_status: false
+  collapse_walkthrough: false
+  changed_files_summary: true
+  sequence_diagrams: true
+  assess_linked_issues: true
+  related_issues: true
+  related_prs: true
+  suggested_labels: true
+  auto_apply_labels: false
+  suggested_reviewers: true
+  auto_assign_reviewers: false
+  poem: false
+  labeling_instructions: []
+  path_filters: []
+  path_instructions: []
+  abort_on_close: true
+  disable_cache: false
+  auto_review:
+    enabled: true
+    auto_incremental_review: true
+    ignore_title_keywords:
+      - WIP
+      - chore(release)
+    labels: []
+    drafts: false
+    base_branches: []
+  finishing_touches:
+    docstrings:
+      enabled: true
+    unit_tests:
+      enabled: true
+  tools:
+    ast-grep:
+      rule_dirs: []
+      util_dirs: []
+      essential_rules: true
+      packages: []
+    shellcheck:
+      enabled: true
+    ruff:
+      enabled: true
+    markdownlint:
+      enabled: true
+    github-checks:
+      enabled: true
+      timeout_ms: 90000
+    languagetool:
+      enabled: true
+      enabled_rules: []
+      disabled_rules: []
+      enabled_categories: []
+      disabled_categories: []
+      enabled_only: false
+      level: default
+    biome:
+      enabled: true
+    hadolint:
+      enabled: true
+    swiftlint:
+      enabled: true
+    phpstan:
+      enabled: true
+      level: default
+    golangci-lint:
+      enabled: true
+    yamllint:
+      enabled: true
+    gitleaks:
+      enabled: true
+    checkov:
+      enabled: true
+    detekt:
+      enabled: true
+    eslint:
+      enabled: true
+    rubocop:
+      enabled: true
+    buf:
+      enabled: true
+    regal:
+      enabled: true
+    actionlint:
+      enabled: true
+    pmd:
+      enabled: true
+    cppcheck:
+      enabled: true
+    semgrep:
+      enabled: true
+    circleci:
+      enabled: true
+    sqlfluff:
+      enabled: true
+    prismaLint:
+      enabled: true
+    oxc:
+      enabled: true
+    shopifyThemeCheck:
+      enabled: true
+    luacheck:
+      enabled: true
+chat:
+  auto_reply: true
+  integrations:
+    jira:
+      usage: auto
+    linear:
+      usage: auto
+knowledge_base:
+  opt_out: false
+  web_search:
+    enabled: true
+  learnings:
+    scope: auto
+  issues:
+    scope: auto
+  jira:
+    usage: auto
+    project_keys: []
+  linear:
+    usage: auto
+    team_keys: []
+  pull_requests:
+    scope: auto
+code_generation:
+  docstrings:
+    language: en-US
+    path_instructions: []
+  unit_tests:
+    path_instructions: []

.cursor/rules/any-inside-generic-functions.mdc

@@ -0,0 +1,42 @@
+---
+description: Any inside generic functions
+globs: **/*.ts,**/*.tsx
+alwaysApply: false
+---
+# Any inside generic functions
+
+But when building generic functions, you may need to use any inside the function body.
+
+This is because TypeScript often cannot match your runtime logic to the logic done inside your types.
+
+One example:
+
+```ts
+const youSayGoodbyeISayHello = <TInput extends 'goodbye' | 'hello'>(
+	input: TInput,
+): TInput extends 'hello' ? 'goodbye' : 'hello' => {
+	if (input === 'goodbye') {
+		return 'hello'; // Error!
+	}
+	return 'goodbye'; // Error!
+};
+```
+
+On the type level (and the runtime), this function returns `goodbye` when the input is `hello`.
+
+There is no way to make this work concisely in TypeScript.
+
+So using `any` is the most concise solution:
+
+```ts
+const youSayGoodbyeISayHello = <TInput extends 'goodbye' | 'hello'>(
+	input: TInput,
+): TInput extends 'hello' ? 'goodbye' : 'hello' => {
+	if (input === 'goodbye') {
+		return 'hello' as any;
+	}
+	return 'goodbye' as any;
+};
+```
+
+Outside of generic functions, use `any` extremely sparingly.

.cursor/rules/default-exports.mdc

@@ -0,0 +1,43 @@
+---
+description: Default export
+globs: **/*.ts,**/*.tsx
+alwaysApply: false
+---
+# Default export
+
+Unless explicitly required by the framework, do not use default exports.
+
+```tsx
+// BAD
+export default function myFunction() {
+  return <div>Hello</div>;
+}
+```
+
+```tsx
+// GOOD
+export function myFunction() {
+  return <div>Hello</div>;
+}
+```
+
+Default exports create confusion from the importing file.
+
+```ts
+// BAD
+import myFunction from './my-function';
+```
+
+```ts
+// GOOD
+import { myFunction } from './my-function';
+```
+
+There are certain situations where a framework may require a default export. For instance, Next.js requires a default export for pages.
+
+```tsx
+// This is fine, if required by the framework
+export default function MyPage() {
+	return <div>Hello</div>;
+}
+```

.cursor/rules/default-typescript.mdc

@@ -0,0 +1,37 @@
+---
+description: Default Typescript
+globs: **/*.ts,**/*.tsx
+alwaysApply: false
+---
+# Default Typescript
+
+## Key Principles
+
+- Use TypeScript for all code. Prefer interfaces over types.
+- Follow the ESLint rules.
+- Use "function" keyword for pure functions.
+- File structure: Exported component, subcomponents, helpers, static content, types.
+- Avoid unnecessary curly braces in conditional statements.
+- For single-line statements in conditionals, omit curly braces.
+- Use concise, one-line syntax for simple conditional statements (e.g., if (condition) doSomething()).
+
+## Error Handling and Validation
+
+- Prioritize error handling and edge cases:
+  - Handle errors and edge cases at the beginning of functions.
+  - Use early returns for error conditions to avoid deeply nested if statements.
+  - Place the happy path last in the function for improved readability.
+  - Avoid unnecessary else statements; use if-return pattern instead.
+  - Use guard clauses to handle preconditions and invalid states early.
+  - Implement proper error logging and user-friendly error messages.
+  - Consider using custom error types or error factories for consistent error handling.
+
+## Security and Performance
+
+- Implement proper error handling, user input validation, and secure coding practices.
+- Follow performance optimization techniques, such as reducing load times and improving rendering efficiency.
+
+## Documentation
+
+- Provide clear and concise comments for complex logic.
+- Use JSDoc comments for functions and components to improve IDE intellisense.

.cursor/rules/discriminated-unions.mdc

@@ -0,0 +1,61 @@
+---
+description: Discriminated unions
+globs: **/*.ts,**/*.tsx
+alwaysApply: false
+---
+# Discriminated unions
+
+Proactively use discriminated unions to model data that can be in one of a few different shapes.
+
+For example, when sending events between environments:
+
+```ts
+interface UserCreatedEvent {
+	data: { email: string; id: string };
+	type: 'user.created';
+}
+
+interface UserDeletedEvent {
+	data: { id: string };
+	type: 'user.deleted';
+}
+
+type Event = UserCreatedEvent | UserDeletedEvent;
+```
+
+Use switch statements to handle the results of discriminated unions:
+
+```ts
+const handleEvent = (event: Event) => {
+	switch (event.type) {
+		case 'user.created': {
+			console.log(event.data.email);
+			break;
+		}
+		case 'user.deleted': {
+			console.log(event.data.id);
+			break;
+		}
+	}
+};
+```
+
+Use discriminated unions to prevent the 'bag of optionals' problem.
+
+For example, when describing a fetching state:
+
+```ts
+// BAD - allows impossible states
+interface FetchingState<TData> {
+	data?: TData;
+	error?: Error;
+	status: 'error' | 'idle' | 'loading' | 'success';
+}
+
+// GOOD - prevents impossible states
+type FetchingState<TData> =
+	| { data: TData; status: 'success' }
+	| { error: Error; status: 'error' }
+	| { status: 'idle' }
+	| { status: 'loading' };
+```

.cursor/rules/enums.mdc

@@ -0,0 +1,49 @@
+---
+description: Enums
+globs: **/*.ts,**/*.tsx
+alwaysApply: false
+---
+# Enums
+
+Do not introduce new enums into the codebase. Retain existing enums.
+
+If you require enum-like behaviour, use an `as const` object:
+
+```ts
+const backendToFrontendEnum = {
+	md: 'MEDIUM',
+	sm: 'SMALL',
+	xs: 'EXTRA_SMALL',
+} as const;
+
+type LowerCaseEnum = keyof typeof backendToFrontendEnum; // "xs" | "sm" | "md"
+
+type UpperCaseEnum = (typeof backendToFrontendEnum)[LowerCaseEnum]; // "EXTRA_SMALL" | "SMALL" | "MEDIUM"
+```
+
+Remember that numeric enums behave differently to string enums. Numeric enums produce a reverse mapping:
+
+```ts
+enum Direction {
+	Up,
+	Down,
+	Left,
+	Right,
+}
+
+const direction = Direction.Up; // 0
+const directionName = Direction[0]; // "Up"
+```
+
+This means that the enum `Direction` above will have eight keys instead of four.
+
+```ts
+enum Direction {
+	Up,
+	Down,
+	Left,
+	Right,
+}
+
+Object.keys(Direction).length; // 8
+```