---

description: Code Patterns and Best Practices

globs: "**/*.{js,ts}"

alwaysApply: true

---

The following conventions MUST be followed in new code.

DON'T report code patterns outside of the examples explicitly listed below:

- Never use `void asyncFunction()` or `asyncFunction().catch(console.error)` - use `runAsynchronously(asyncFunction)` instead

- Use `parseJson`/`stringifyJson` from `stack-shared/utils/json` instead of `JSON.parse`/`JSON.stringify`

- Instead of Vercel `waitUntil`, use `runAsynchronously(promise, { promiseCallback: waitUntil })`

- Don't concatenate URLs as strings - avoid patterns like `/users/${userId}`

- Replace non-null assertions with `?? throwErr("message", { extraData })` pattern

- Properly handle async operations with try/catch blocks

- Use helper functions for validation and environment variables

# Solution

Fix code pattern violations by:

- Wrapping async calls with runAsynchronously

- Importing parseJson/stringifyJson from stack-shared/utils/json

- Using runAsynchronously with promiseCallback for waitUntil

- Using proper URL construction utilities

- Replacing ! assertions with ?? throwErr pattern

---

description: Naming Conventions

globs: "**/*.{js,ts}"

alwaysApply: true

---

Code changes MUST follow the naming guidelines below.

DON'T report any other naming issues.

- Use `snake_case` for anything that goes over HTTP in REST APIs, `camelCase` for JavaScript elsewhere

- `captureError`'s first argument should be a machine-readable ID without whitespaces (e.g., `'user-sign-up-email'` not `'Email failed to send'`)

- When doing OAuth flows, specify the type (inner/outer/external) in variable names, comments, and error messages

- Use descriptive names that clearly indicate purpose and context

- Avoid abbreviations unless they are widely understood

# Solution

Fix naming inconsistencies by:

- Converting API parameters to snake_case

- Making captureError IDs machine-readable with hyphens

- Adding OAuth type prefixes to variable names