Skip to content

Add React/Next.js, TypeScript, Python, Go production rules #300

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
oliviacraft wants to merge 5 commits into
base: main
Choose a base branch
from
Open

Add React/Next.js, TypeScript, Python, Go production rules #300

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
ac87484
Add rules/react-nextjs-production/.cursorrules
oliviacraft May 31, 2026
f1cf9d2
Add rules/typescript-strict-production/.cursorrules
oliviacraft May 31, 2026
52cdadd
Add rules/python-fastapi-production/.cursorrules
oliviacraft May 31, 2026
ae4cd00
Add rules/go-production/.cursorrules
oliviacraft May 31, 2026
8d8fef0
fix: update Python title to Python FastAPI Production
oliviacraft Jun 3, 2026
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
9 changes: 9 additions & 0 deletions rules/go-production/.cursorrules
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,9 @@
.cursorrules — Go Production

- Never ignore returned error with _. Handle or return every error.
- Wrap with context: fmt.Errorf("functionName: %w", err).
- Define interfaces at the consumer package. Keep interfaces to 1-2 methods.
- ctx context.Context as first parameter in every I/O function.
- Every goroutine has a clear owner and shutdown path. Use errgroup.
- Always name struct fields. No positional initialization.
- Table-driven tests with t.Run(tt.name, ...).
9 changes: 9 additions & 0 deletions rules/python-fastapi-production/.cursorrules
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,9 @@
.cursorrules — Python FastAPI Production

- Every function signature must include type hints.
- Never bare except: — catch specific exceptions or re-raise.
- Pydantic BaseModel for API boundary data. @dataclass for internal structures.
- Pass dependencies as parameters. No global variables in business logic.
- Always pathlib.Path. / operator for path joining.
- Never time.sleep() in async. Use asyncio.sleep().
- Validate env vars at startup. No os.environ.get() silent defaults.
9 changes: 9 additions & 0 deletions rules/react-nextjs-production/.cursorrules
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,9 @@
.cursorrules — React + Next.js App Router

- Default to Server Components. Add "use client" only for hooks/browser APIs/event handlers.
- Fetch data in Server Components. Never fetch in useEffect.
- Use server actions for mutations, not client-side API route calls.
- One component per file. File name = component name (PascalCase).
- Define explicit interface Props. Never use any as prop type.
- Every async route needs a sibling loading.tsx and error.tsx.
- Use next/image instead of img. Use next/font instead of Google Fonts link tags.
Comment on lines +1 to +9

@coderabbitai coderabbitai Bot May 31, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

⚠️ Potential issue | 🟡 Minor | ⚡ Quick win

🧩 Analysis chain

🌐 Web query:

Next.js App Router best practices 2026 Server Components server actions loading error

💡 Result:

Best practices for Next.js App Router (2026) around Server Components, Server Actions, streaming/loading, and handling the common “loading / Server Actions error” issues (incl. “Failed to find Server Action”): 1) Default to Server Components; isolate interactivity in Client Components - In the App Router, Server Components are the default; add “use client” only when you need browser-only behavior (state/effects/event handlers/browser APIs) (DEV explanation, aligned with Next.js RSC model) [1]. 2) Use Server Components for data fetching; use Server Actions for mutations - Next.js Server Functions (Server Actions) are designed for server-side mutations; for reading data, use Server Components (and/or Route Handlers) (official docs) [2][3]. 3) Handle “expected” errors in Server Actions with return values + useActionState - Next.js distinguishes expected errors vs unexpected exceptions, and for Server Functions recommends modeling expected errors as return values (not try/catch) and surfacing them via the useActionState hook (official docs) [4]. - Practical pattern: in a Client Component, call useActionState(action, initialState) and render UI based on state (official example pattern) [4]. 4) Use error.tsx / not-found.tsx boundaries for Server Component render errors - For route segment error boundaries in App Router, use error.tsx (and not-found.tsx for 404-like missing resources) (Next.js Learn) [5]. - error boundaries catch errors during rendering; they’re not a catch-all for all runtime failures [4]. 5) Loading UX in App Router: prefer loading.tsx/loading.js + Suspense boundaries - Next.js supports route-segment loading UI via the special loading.js file colocated next to page.js; it wraps that segment in a Suspense boundary and shows the fallback instantly while page content streams [6][7]. - Important caveat: if the layout accesses uncached/runtime data (e.g., cookies, headers, or uncached fetches), loading.js may not show a fallback for it; to preserve streaming, move that work into page.js or wrap runtime access in your own Suspense boundary [6][7]. 6) Server Action loading/pending states: use useActionState (and pending) for submit buttons - While a Server Function is executing, you can show a loading indicator using useActionState, which returns a pending boolean (official docs) [2][8]. 7) Common “Server Actions error” causes and fixes A) “Failed to find Server Action … This request might be from an older or newer deployment” (very common in production) - This error can happen when the server can’t match the incoming request to a known Server Action in the currently running build (discussion/issue examples show the exact message) [9][10]. - Operational best practice: ensure you deploy the same build artifact consistently and avoid serving mismatched builds between instances (the error message itself indicates a deployment/build mismatch) [9]. - If you’re self-hosting/multi-instance, also ensure NEXT_SERVER_ACTIONS_ENCRYPTION_KEY is set at build time (so action IDs/encryption are consistent across builds/instances) [9]. B) Server Action wiring mistakes that produce “Invalid action” / wrong action prop - Make sure the function used as a form action is actually a Server Action (marked with “use server” and is async) and is imported from the correct server module scope; otherwise the action prop is invalid and you’ll see errors like “Invalid value for prop action …” (summary of typical causes) [11]. C) “Server Actions seem to break after upgrading Next.js” - There are documented regressions where Server Actions fail (e.g., “Failed to find Server Action” after upgrading from 14.2.7 to 14.2.8) (GitHub issues) [12][10]. - If you hit this, verify you’re on a fixed version and reproduce with minimal action imports; also check action/module boundaries and ensure the server action is not accidentally converted to something else by imports/usage patterns (examples indicate the error is tied to runtime build/action mapping) [10]. 8) A concise “2026 mental model” checklist - Reads: Server Components (streaming where possible) [2][3]. - Writes: Server Actions (use “use server”, return structured expected errors, revalidate/refresh appropriately) [2][3]. - Errors: useActionState for expected Server Function errors [4]; use error.tsx/not-found.tsx for render-time boundaries [5][4]. - Loading: loading.tsx/loading.js for route segments; avoid uncached/runtime data in layout unless wrapped correctly [6][7]. - Production reliability: watch for “Failed to find Server Action” deployment/build mismatches; ensure consistent build artifacts + required encryption key configuration if applicable [9]. If you paste your specific stack trace (especially the exact message and the files involved: action module, form component, and route segment level of loading/error boundaries), I can map it to the likely bucket above and suggest the minimal fix.

Citations:

🌐 Web query:

Next.js next/image next/font recommended usage 2026

💡 Result:

Recommended usage (Next.js in 2026): 1) next/image - Always size the image to avoid layout shift (CLS). The docs state width/height are used to infer aspect ratio and avoid layout shift, and they do not determine rendered size (CSS does). [1][2] - If you know the height/width, use width/height. - If height/width are unknown, use fill. When using fill, the parent must have position: relative (or fixed/absolute depending on context), and fill expands to the parent. [1][3] - For remote images, Next.js cannot inspect remote files at build time, so you must provide width and height manually (or use fill). [2] - If the image is responsive (especially with fill), provide a realistic sizes prop; without sizes the browser may download unnecessarily large images. [3] - For above-the-fold / LCP images, newer guidance de-emphasizes priority and instead points to using loading="eager" or fetchPriority="high". [4] Example patterns (officially consistent with the docs) - Known aspect ratio (width/height): ... [1] - Unknown aspect ratio (fill): <div style={{ position: 'relative', width: '400px', height: '300px' }}> <Image src="/photo.jpg" alt="Photo" fill style={{ objectFit: 'cover' }} /> [3] - Remote image (manually provide dimensions): ... [2] 2) next/font - Use next/font (next/font/google or next/font/local) to get automatic font optimization and self-hosting, eliminating external network requests and helping prevent layout shift. [5][6] - Apply fonts via the className returned by the loader, and to make a font global in the App Router, add it in the Root Layout (analogously _app for Pages Router). [5][6] - Prefer variable fonts when possible; otherwise specify required weights. [5] 3) Putting them together (practical 2026 checklist) - Fonts: import via next/font and apply the returned className at the appropriate layout/root. [5][6] - Images: every next/image instance should be either (a) width/height (so Next can reserve aspect-ratio space) or (b) fill with a sized parent; for fill/responsive layouts, set sizes. [1][3] - Remote images: always provide width/height (or use fill) since Next can’t read remote dimensions at build time. [2] - For the LCP/hero image: use loading="eager" or fetchPriority="high" (the docs/implementation guidance updates away from relying on the older priority prop). [4]

Citations:

Soften/adjust App Router rules for loading/error and mutation guidance

  • loading.tsx / error.tsx are recommended route-segment UI/boundaries, but they’re not required for every async route segment (missing files fall back to Next.js defaults), so revise the “Every async route needs…” wording (line 8).
  • The “Server Actions for mutations, not client-side API route calls” and “Never fetch in useEffect” rules are too absolute for current docs; adjust to “prefer” / “use when appropriate” (lines 4-5) to avoid steering codegen into unnecessary patterns.
🤖 Prompt for AI Agents 
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@rules/react-nextjs-production/.cursorrules` around lines 1 - 9, Update the
.cursorrules text to soften absolutes: change the sentence about "Every async
route needs a sibling loading.tsx and error.tsx" to state that loading.tsx and
error.tsx are recommended route-segment UI/boundaries and that missing files
fall back to Next.js defaults; likewise modify the rules referencing "Server
Actions for mutations, not client-side API route calls" and "Never fetch in
useEffect" to use wording like "prefer Server Actions for mutations when
appropriate" and "prefer fetching in Server Components; avoid useEffect for data
fetching when possible," so the file mentions recommendation/preference rather
than strict prohibition for "loading.tsx"/"error.tsx", "Server Actions", and
"useEffect".

9 changes: 9 additions & 0 deletions rules/typescript-strict-production/.cursorrules
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,9 @@
.cursorrules — TypeScript Strict Mode

- tsconfig.json must have "strict": true. Never disable strict checks.
- No any. Use unknown + type guards, or as Type only at I/O boundaries.
- Every exported function needs explicit return type including async (Promise<T>).
- Model state as discriminated unions: { status: "loading" } | { status: "success"; data: T }.
- Readonly<T> for immutable data. as const for config objects.
- Validate env vars at startup. Never process.env.FOO in business logic.
- No TypeScript enum. Use const object + typeof union.
Loading