Add React/Next.js, TypeScript, Python, Go production rules#300
Add React/Next.js, TypeScript, Python, Go production rules#300oliviacraft wants to merge 4 commits into
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
✅ Files skipped from review due to trivial changes (1)
📝 WalkthroughWalkthroughFour ChangesProduction Coding Rules for Multiple Tech Stacks
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~3 minutes Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 inconclusive)
✅ Passed checks (4 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 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (2)
rules/python-fastapi-production/.cursorrules (2)
1-1: ⚡ Quick winUpdate title to match directory name and scope.
The title says "Python Production" but the directory is
python-fastapi-productionand the rules specifically reference FastAPI-related patterns (e.g., PydanticBaseModelat API boundaries). Consider updating to "Python/FastAPI Production" for consistency.📝 Suggested title update
-.cursorrules — Python Production +.cursorrules — Python/FastAPI Production🤖 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/python-fastapi-production/.cursorrules` at line 1, Update the rules title string "Python Production" to reflect the directory and scope by changing it to "Python/FastAPI Production" (or similar) so it explicitly references FastAPI; locate the title declaration in the .cursorrules content where "Python Production" appears and replace it with "Python/FastAPI Production", and ensure any header or metadata that repeats the title is updated consistently.
9-9: ⚡ Quick winClarify what "silent defaults" means.
The phrase "No os.environ.get() silent defaults" could be interpreted multiple ways. Consider being more explicit about the problematic pattern.
📝 Suggested clarification
-Validate env vars at startup. No os.environ.get() silent defaults. +Validate required env vars at startup. No os.environ.get(key, default) fallbacks that hide missing config.Or alternatively:
-Validate env vars at startup. No os.environ.get() silent defaults. +Explicitly validate env vars at startup. Fail fast on missing required config—avoid os.environ.get() with fallback defaults.🤖 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/python-fastapi-production/.cursorrules` at line 9, Replace the ambiguous phrase "No os.environ.get() silent defaults" with an explicit description and examples: state that patterns like os.environ.get('FOO', 'default') or os.getenv('FOO', 'default') which silently fall back to a default are disallowed, and recommend the allowed alternatives (e.g., use os.environ['FOO'] to fail fast or a centralized validator at startup that raises a clear error). Update the rule text so it contains both the problematic code snippets and the preferred patterns (and mention the rule's intent to validate env vars at startup).
🤖 Prompt for all review comments with 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.
Inline comments:
In `@rules/react-nextjs-production/.cursorrules`:
- Around line 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".
---
Nitpick comments:
In `@rules/python-fastapi-production/.cursorrules`:
- Line 1: Update the rules title string "Python Production" to reflect the
directory and scope by changing it to "Python/FastAPI Production" (or similar)
so it explicitly references FastAPI; locate the title declaration in the
.cursorrules content where "Python Production" appears and replace it with
"Python/FastAPI Production", and ensure any header or metadata that repeats the
title is updated consistently.
- Line 9: Replace the ambiguous phrase "No os.environ.get() silent defaults"
with an explicit description and examples: state that patterns like
os.environ.get('FOO', 'default') or os.getenv('FOO', 'default') which silently
fall back to a default are disallowed, and recommend the allowed alternatives
(e.g., use os.environ['FOO'] to fail fast or a centralized validator at startup
that raises a clear error). Update the rule text so it contains both the
problematic code snippets and the preferred patterns (and mention the rule's
intent to validate env vars at startup).
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: a7b0f8cb-0f9d-4ee8-8a95-9ee23719e912
📒 Files selected for processing (4)
rules/go-production/.cursorrulesrules/python-fastapi-production/.cursorrulesrules/react-nextjs-production/.cursorrulesrules/typescript-strict-production/.cursorrules
| .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. |
There was a problem hiding this comment.
🧩 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:
- 1: https://dev.to/nayankyada/nextjs-app-router-tutorial-guide-2026-from-pages-router-to-production-4fgg
- 2: https://nextjs.org/docs/app/getting-started/mutating-data
- 3: https://nextjs.org/docs/13/app/building-your-application/data-fetching/server-actions-and-mutations
- 4: https://nextjs.org/docs/app/getting-started/error-handling
- 5: https://nextjs.org/learn/dashboard-app/error-handling
- 6: https://nextjs.org/docs/14/app/building-your-application/routing/loading-ui-and-streaming
- 7: https://nextjs.org/docs/app/api-reference/file-conventions/loading
- 8: https://nextjs.im/docs/app/getting-started/mutating-data/
- 9: https://scalabledeveloper.com/posts/failed-to-find-server-action/
- 10: Failed to find Server Action - next dev - v14.2.8 vercel/next.js#69882
- 11: https://www.krapton.com/blog/mastering-nextjs-server-actions-fixing-invalid-action-errors-in-2026-2701a8
- 12: Server actions regression in 14.2.8: “Failed to find Server Action” vercel/next.js#69756
🌐 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): 
Citations:
- 1: https://nextjs.im/docs/15/app/api-reference/components/image/
- 2: https://nextjs.org/docs/app/getting-started/images
- 3: https://vercel-next-js.mintlify.app/api-reference/components/image
- 4: vercel/next.js@07e9324
- 5: https://nextjs.org/docs/app/getting-started/fonts
- 6: https://nextjs.org/docs/pages/getting-started/fonts
Soften/adjust App Router rules for loading/error and mutation guidance
loading.tsx/error.tsxare 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".
|
Hi! Just checking in on this PR. Happy to adjust the format if needed — let me know if there are any style requirements for new entries. Thanks for maintaining this resource! |
PatrickJS
force-pushed
the
add-mdc-production-rules
branch
from
bb84ab3 to
ae4cd00
Compare
1 participant
Production-tested rules for 4 common stacks
Adding
.cursorrulesfiles for 4 stacks based on the most common AI code generation failure modes:Each rule targets the specific pattern AI generates incorrectly for that stack — not generic best practices.
These files follow the existing
.cursorrulesformat in this repo. There's also an.mdcversion available for Cursor agent mode (which uses a different format): cursor-mdc-rulesSummary by CodeRabbit