React (Vite)

Single-page React application built with Vite. No server — everything ships to the browser.

adds it to an existing project · no account needed
Currentas published in v1.5.1

The rule

This is the whole text, exactly as your agent receives it. Nothing is held back for the paid tier.

Everything here is public

There is no server. The bundle ships to the browser in full.

  • No secret in a VITE_* variable — it is inlined and readable by anyone.
  • Authorisation is enforced by the API. Hiding a button is presentation, not security.

Components

  • Function components with typed props. One screen per file; extract at ~150 lines.
  • Lazy-load route components, or every visitor downloads every screen.
  • Keys on lists must be stable ids, never the array index.

State and effects

  • Effects run twice in development under StrictMode, deliberately. Make them idempotent rather than working around it.
  • Cancel in-flight requests on unmount, or use a query library that does.
  • Do not fetch in useEffect without cancellation — races and leaks.
  • Server state and UI state are different concerns; do not store fetched data alongside form state.

Structure

  • Group by feature, not by file type.
  • API access lives in src/services/. Components call services, never fetch directly.

Never

  • Never trust anything the client computed for an authorisation decision.
  • Never ship source maps publicly without deciding to.
  • Never verify only against npm run dev — the build behaves differently.

6 formats, one per tool

Each tab is the file that tool actually reads, at the path it actually looks in. Knowing where each one looks is most of the work of supporting it.

.cursor/rules/react.mdchand-written
---
description: React and Vite conventions
globs: ["src/**/*.tsx", "src/**/*.ts", "vite.config.*"]
alwaysApply: false
---

# React (Vite)

## Everything here is public

There is no server. The bundle ships to the browser in full.

- No secret in a `VITE_*` variable — it is inlined and readable by anyone.
- Authorisation is enforced by the API. Hiding a button is presentation, not
  security.

## Components

- Function components with typed props. One screen per file; extract at ~150
  lines.
- Lazy-load route components, or every visitor downloads every screen.
- Keys on lists must be stable ids, never the array index.

## State and effects

- Effects run twice in development under StrictMode, deliberately. Make them
  idempotent rather than working around it.
- Cancel in-flight requests on unmount, or use a query library that does.
- Do not fetch in `useEffect` without cancellation — races and leaks.
- Server state and UI state are different concerns; do not store fetched data
  alongside form state.

## Structure

- Group by feature, not by file type.
- API access lives in `src/services/`. Components call services, never `fetch`
  directly.

## Never

- Never trust anything the client computed for an authorisation decision.
- Never ship source maps publicly without deciding to.
- Never verify only against `npm run dev` — the build behaves differently.

Hand-written by the module author, frontmatter and all. It is the source the four derived formats are rendered from, so a correction lands here first.

What else this module writes

The rule is one file of several. Selecting React (Vite) contributes all of this too — merged with every other module you pick, with conflicts resolved rather than duplicated.

Environment
VITE_API_URLrequiredBase URL of the API this app calls.
VITE_APP_ENVoptionalEnvironment label used for diagnostics and feature gating.
Dependencies
react^19.2.3react-dom^19.2.3react-router-dom^7.18.0vite^8.2.0dev@vitejs/plugin-react^6.0.0dev@types/react^19.2.0dev@types/react-dom^19.2.0dev
Folders
src/components/src/features/src/hooks/src/services/src/lib/public/

Advisory history

Every time this rule turned out to be wrong, and what we did about it.

No corrections yet

This rule has been accurate since it was published. That is a fact about the rule, not a promise about the future — which is the whole reason this section exists.

Pro tells you the day a correction lands that affects a repo you actually have.

See what Pro adds →

Rules people add alongside this one

Put this rule in a real project

The wizard picks the rest of the stack with you, writes all 6 formats, and leaves a manifest so check can tell you when any of it drifts.