From a4cb410d3e26f8e2af6e764a9b9ce0588ab39afc Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Carl-Gerhard=20Lindesva=CC=88rd?= Date: Wed, 25 Feb 2026 11:13:12 +0100 Subject: [PATCH] disabled ultracite for a minute --- .claude/CLAUDE.md | 37 ---------- .claude/settings.json | 15 ---- .cursor/hooks.json | 10 --- .cursor/rules/feature-pages.mdc | 91 ----------------------- .cursor/rules/ultracite.mdc | 123 -------------------------------- 5 files changed, 276 deletions(-) delete mode 100644 .claude/settings.json delete mode 100644 .cursor/hooks.json delete mode 100644 .cursor/rules/feature-pages.mdc delete mode 100644 .cursor/rules/ultracite.mdc diff --git a/.claude/CLAUDE.md b/.claude/CLAUDE.md index 1d4ac03e..8d33962e 100644 --- a/.claude/CLAUDE.md +++ b/.claude/CLAUDE.md @@ -79,19 +79,6 @@ Uses TanStack Router with file-based routing (`src/routes/`). State management v ### API (apps/api) Fastify server with tRPC integration. Route files in `src/routes/`. Hooks for IP extraction, request logging, timestamps. Built with `tsdown`. - -# Ultracite Code Standards - -This project uses **Ultracite**, a zero-config preset that enforces strict code quality standards through automated formatting and linting. - -## Quick Reference - -- **Format code**: `pnpm dlx ultracite fix` -- **Check for issues**: `pnpm dlx ultracite check` -- **Diagnose setup**: `pnpm dlx ultracite doctor` - -Biome (the underlying engine) provides robust linting and formatting. Most issues are automatically fixable. - --- ## Core Principles @@ -179,27 +166,3 @@ Write code that is **accessible, performant, type-safe, and maintainable**. Focu **Solid/Svelte/Vue/Qwik:** - Use `class` and `for` attributes (not `className` or `htmlFor`) - ---- - -## Testing - -- Write assertions inside `it()` or `test()` blocks -- Avoid done callbacks in async tests - use async/await instead -- Don't use `.only` or `.skip` in committed code -- Keep test suites reasonably flat - avoid excessive `describe` nesting - -## When Biome Can't Help - -Biome's linter will catch most issues automatically. Focus your attention on: - -1. **Business logic correctness** - Biome can't validate your algorithms -2. **Meaningful naming** - Use descriptive names for functions, variables, and types -3. **Architecture decisions** - Component structure, data flow, and API design -4. **Edge cases** - Handle boundary conditions and error states -5. **User experience** - Accessibility, performance, and usability considerations -6. **Documentation** - Add comments for complex logic, but prefer self-documenting code - ---- - -Most formatting and common issues are automatically fixed by Biome. Run `pnpm dlx ultracite fix` before committing to ensure compliance. diff --git a/.claude/settings.json b/.claude/settings.json deleted file mode 100644 index f09fa2eb..00000000 --- a/.claude/settings.json +++ /dev/null @@ -1,15 +0,0 @@ -{ - "hooks": { - "PostToolUse": [ - { - "matcher": "Write|Edit", - "hooks": [ - { - "type": "command", - "command": "pnpm dlx ultracite fix" - } - ] - } - ] - } -} \ No newline at end of file diff --git a/.cursor/hooks.json b/.cursor/hooks.json deleted file mode 100644 index 0c86507a..00000000 --- a/.cursor/hooks.json +++ /dev/null @@ -1,10 +0,0 @@ -{ - "version": 1, - "hooks": { - "afterFileEdit": [ - { - "command": "pnpm dlx ultracite fix" - } - ] - } -} \ No newline at end of file diff --git a/.cursor/rules/feature-pages.mdc b/.cursor/rules/feature-pages.mdc deleted file mode 100644 index c37e6e25..00000000 --- a/.cursor/rules/feature-pages.mdc +++ /dev/null @@ -1,91 +0,0 @@ ---- -description: Guide for creating and editing feature landing pages on the public site -globs: apps/public/content/features/**,apps/public/src/app/(content)/features/**,apps/public/src/lib/features.ts -alwaysApply: false ---- - -# Feature Landing Pages - -Feature pages live at `/features/[slug]` and follow the same JSON-driven pattern as the compare pages (`/compare/[slug]`). - -## Architecture - -- **Content**: JSON files in `apps/public/content/features/[slug].json` -- **Types & loaders**: `apps/public/src/lib/features.ts` (interfaces + `getFeatureData`, `getAllFeatureSlugs`, `loadFeatureSourceSync`) -- **Source export**: `featureSource` in `apps/public/src/lib/source.ts` (sync-loaded at build time) -- **Dynamic route**: `apps/public/src/app/(content)/features/[slug]/page.tsx` -- **Index page**: `apps/public/src/app/(content)/features/page.tsx` -- **Sitemap**: Feature pages are registered in `apps/public/src/app/sitemap.ts` - -## Adding a new feature page - -1. Create `apps/public/content/features/[slug].json` matching the `FeatureData` interface -2. That's it — the dynamic route, index page, sitemap, and source all pick it up automatically - -## JSON schema (FeatureData) - -Every JSON file must have these fields: - -``` -slug - URL slug (e.g. "event-tracking") -short_name - Short internal name for nav, footer, links (e.g. "Event tracking", "Funnels") -seo.title - Page title for SEO -seo.description - Meta description -seo.keywords - Optional keyword array -hero.heading - H1 text -hero.subheading - Subtitle under H1 -hero.badges - Array of short feature-specific perks (NOT generic OpenPanel perks) -definition.title - Optional section heading (e.g. "What is event tracking?") -definition.text - Markdown string explaining the feature in depth (supports bold, lists, code, links) -capabilities_section.title - Section heading for capabilities -capabilities_section.intro - Optional intro text -capabilities - Array of { title, description, icon? } -screenshots - Array of { src?, srcDark?, srcLight?, alt, caption? } (up to 3 shown between sections; use `src` for a single image or `srcDark`+`srcLight` for theme variants) -how_it_works - Optional { title, intro?, steps: [{ title, description }] } -use_cases - { title, intro?, items: [{ title, description }] } -related_features - Array of { slug, title, description? } linking to other feature pages -faqs - { title, intro?, items: [{ question, answer }] } -cta - { label, href } -``` - -## Content guidelines - -- **short_name**: Use for footer, nav, and any compact link list. Keep it to 1–3 words (e.g. "Event tracking", "Funnels"). The full `hero.heading` stays for the page H1 and SEO. -- **Badges**: Should describe what *this feature* does, not generic OpenPanel selling points -- **Definition**: Rich markdown — use bold, bullet lists, inline code for event names. This is the main SEO content block -- **Related features**: Only link to feature pages that already exist (to avoid 404s) -- **Screenshots**: Feature-specific screenshots go in `/public/features/` (e.g. `feature-events-list.webp`). Generic screenshots are in `/public/screenshots/` with dark/light .webp variants. Use `src` for single images or `srcDark`+`srcLight` for theme pairs - -## Section components - -Located in `features/[slug]/_components/`: - -| Component | Reuses | -|-----------|--------| -| `feature-hero.tsx` | `HeroContainer`, `SectionHeader`, `GetStartedButton`, `Perks` | -| `what-it-is.tsx` | `Section`, `SectionHeader`, `react-markdown` | -| `capabilities.tsx` | `FeatureCard`, `Section`, `SectionHeader` | -| `how-it-works.tsx` | `Section`, `SectionHeader` | -| `feature-use-cases.tsx` | `Section`, `SectionHeader` | -| `related-features.tsx` | `FeatureCardContainer`, `Section`, `SectionHeader` | -| `feature-faq.tsx` | `Faqs`, `FaqItem`, `Section`, `SectionHeader`, JSON-LD schema | - -The page also reuses `WindowImage` and `CtaBanner` directly. - -## Planned feature slugs - -From the roadmap (create JSON files as needed): - -- `event-tracking` ✅ -- `funnels` ✅ -- `session-tracking` ✅ -- `retention` ✅ -- `identify-users` ✅ -- `revenue-tracking` ✅ -- `data-visualization` ✅ -- `product-analytics` -- `web-analytics` ✅ -- `conversion` ✅ -- `integrations` ✅ -- `notifications` ✅ -- `share-and-collaborate` ✅ diff --git a/.cursor/rules/ultracite.mdc b/.cursor/rules/ultracite.mdc deleted file mode 100644 index 76b4361d..00000000 --- a/.cursor/rules/ultracite.mdc +++ /dev/null @@ -1,123 +0,0 @@ -# Ultracite Code Standards - -This project uses **Ultracite**, a zero-config preset that enforces strict code quality standards through automated formatting and linting. - -## Quick Reference - -- **Format code**: `pnpm dlx ultracite fix` -- **Check for issues**: `pnpm dlx ultracite check` -- **Diagnose setup**: `pnpm dlx ultracite doctor` - -Biome (the underlying engine) provides robust linting and formatting. Most issues are automatically fixable. - ---- - -## Core Principles - -Write code that is **accessible, performant, type-safe, and maintainable**. Focus on clarity and explicit intent over brevity. - -### Type Safety & Explicitness - -- Use explicit types for function parameters and return values when they enhance clarity -- Prefer `unknown` over `any` when the type is genuinely unknown -- Use const assertions (`as const`) for immutable values and literal types -- Leverage TypeScript's type narrowing instead of type assertions -- Use meaningful variable names instead of magic numbers - extract constants with descriptive names - -### Modern JavaScript/TypeScript - -- Use arrow functions for callbacks and short functions -- Prefer `for...of` loops over `.forEach()` and indexed `for` loops -- Use optional chaining (`?.`) and nullish coalescing (`??`) for safer property access -- Prefer template literals over string concatenation -- Use destructuring for object and array assignments -- Use `const` by default, `let` only when reassignment is needed, never `var` - -### Async & Promises - -- Always `await` promises in async functions - don't forget to use the return value -- Use `async/await` syntax instead of promise chains for better readability -- Handle errors appropriately in async code with try-catch blocks -- Don't use async functions as Promise executors - -### React & JSX - -- Use function components over class components -- Call hooks at the top level only, never conditionally -- Specify all dependencies in hook dependency arrays correctly -- Use the `key` prop for elements in iterables (prefer unique IDs over array indices) -- Nest children between opening and closing tags instead of passing as props -- Don't define components inside other components -- Use semantic HTML and ARIA attributes for accessibility: - - Provide meaningful alt text for images - - Use proper heading hierarchy - - Add labels for form inputs - - Include keyboard event handlers alongside mouse events - - Use semantic elements (`