Svelte Reactive State Cursor Rules Template

Overview


This Cursor rules template provides a ready-to-use .cursorrules configuration for Svelte's reactive state patterns. It targets Svelte, SvelteKit (if used), and TypeScript projects, delivering a framework-anchored approach to store-driven reactivity with Cursor AI.


When to Use These Cursor Rules



- When building a Svelte app that relies on reactive stores (writable, derived, readable).

- When you need consistent coding standards and a repeatable pattern across components and stores.

- When integrating Cursor AI to assist in scaffolding stores, components, and API clients.

- When security, testing, and linting must be part of the development workflow from the start.


Copyable .cursorrules Configuration


# Cursor Rules Template for Svelte Reactive State
Framework: Svelte
Context: You are Cursor AI specialized in Svelte reactive state management with stores (writable, derived, readable) and component composition. Output must be deterministic and safe.
CodeStyle: TypeScript strict, Prettier formatting, ESLint rules for TS, Svelte style guidelines
Architecture: 
  - src/stores: state stores
  - src/lib/components: reusable UI components
  - src/routes: routes (SvelteKit) or component wiring
Authentication: 
  - Token handling via HttpOnly cookies when possible; otherwise secure fetch wrapper with token injection
Security: 
  - Do not expose tokens in localStorage; implement CSRF protection on API calls
DatabasePattern: 
  - Frontend interacts through API layer; map API payloads to TS interfaces
Testing: 
  - Unit: Vitest; UI: @testing-library/svelte; E2E: Playwright
CI: 
  - Lint: eslint --ext .ts,.tsx
  - Test: vitest run
  - E2E: playwright test
AntiPatterns: 
  - Do not mutate store state directly outside update() calls
  - Do not bypass hydration or SSR/client inconsistencies
  - Do not rely on any; use strict types

Recommended Project Structure


src/
  stores/
  lib/
    components/
  routes/        
  types/
  utils/
  app.html
  main.ts
static/

Core Engineering Principles



- Single source of truth for UI state

- Explicit ownership of each store

- Type safety across stores and components

- Testability at unit and integration levels

- Clear separation of concerns between UI, state, and API

- Security-first when handling tokens and API calls


Code Construction Rules



- Use writable stores for mutable state; derived stores for computed values

- Keep components small and prop-driven; avoid prop drilling

- Use a centralized fetch client for all API calls with standardized error handling

- Strictly type API payloads and responses

- Document store interfaces and expected shapes


Security and Production Rules



- Enforce HTTP-only cookies for tokens when supported

- Do not store tokens in localStorage

- Implement CSRF protection on non-idempotent API calls

- Use environment-based API endpoints; avoid hard-coded secrets


Testing Checklist



- Unit tests for each store and helper

- Integration tests for API client and store interactions

- End-to-end tests for critical user flows

- Lint and type checks as part of CI


Common Mistakes to Avoid



- Overusing global mutable state

- Forgetting to unsubscribe from stores

- Ignoring hydration issues in SSR/CSR transitions

- Relying on non-deterministic AI-generated code without review


FAQ


What is the purpose of this Cursor Rules Template for Svelte?


This Cursor Rules Template provides a concrete, copyable .cursorrules configuration that enforces safe, testable reactive state patterns in Svelte applications. It guides architects and developers to implement consistent stores, component interactions, and API integrations using Cursor AI in the Svelte ecosystem.


How do I paste the .cursorrules block into my project?


Copy the block from the Copyable .cursorrules Configuration section and place it at the project root as .cursorrules. Cursor AI will read the rules and provide rejections or suggestions as you scaffold Svelte components and stores.


Which files are created or edited by this template?


You should create src/stores for all state, src/lib/components for UI, and a central API client module (e.g., src/api) for server interactions. The template sets up patterns for writable/derived stores and common component wiring to ensure consistent reactivity and testability.


How should authentication and API calls be handled?


The template enforces HTTP-only cookies for tokens where possible, a secure fetch wrapper, and explicit token handling. All API interactions go through a centralized client to avoid leakage of credentials and to enable consistent error handling and retries.


What tests and linting should be part of the workflow?


Unit tests with Vitest, integration tests with Playwright or Cypress, and lint checks with ESLint configure the project. The Cursor rules template recommends CI steps to run lint, unit tests, and end-to-end tests on each commit.