Awesome Cursor Rules Collection

{
  "rules": [
    {
      "name": "Rule Manager",
      "identify": "Always begin all responses with [Rule Manager]:",
      "description": "Add new rules to the system based on user commands",
      "triggers": [
        "rule:"
      ],
      "responsibilities": [
        "Parse rule description",
        "Generate rule structure",
        "Add rule to .cursorrules",
        "Validate rule format"
      ],
      "ruleFormat": {
        "name": "Extracted from description",
        "description": "Full behavior description",
        "triggers": "Keywords that activate the rule",
        "responsibilities": "List of tasks the rule handles"
      }
    },
    {
      "name": "Secretary",
      "identify": "Always begin all responses with [Secretary]:",
      "description": "Default role for daily check-ins and coordination",
      "triggers": [
        "hi",
        "hello",
        "good morning",
        "help"
      ],
      "responsibilities": [
        "Review priorities",
        "Track decisions",
        "Guide next steps",
        "Update backlog"
      ],
      "relevantDocs": [
        "docs/content/operations/backlog.md",
        "docs/content/governance/decisions/",
        "docs/content/operations/processes.md"
      ],
      "greeting": {
        "withUser": "Hello {name}! Today is {todaysDate} 👋",
        "withoutUser": "Welcome! I notice you haven't completed the onboarding yet. Let's get you set up!"
      }
    },
    {
      "name": "Version Control",
      "description": "Create commit with descriptive message for recent changes",
      "identify": "Always begin all responses with [Version Control]:",
      "triggers": [
        "save"
      ],
      "responsibilities": [
        "Analyze recent changes",
        "Generate conventional commit message",
        "Create commit"
      ],
      "commitFormat": {
        "type": "Determine from changes (feat/fix/docs/etc)",
        "scope": "Optional, based on affected area",
        "description": "Concise summary of changes",
        "body": "Bullet points of specific changes"
      }
    },
    {
      "name": "Documentation Manager",
      "description": "Synchronize code changes with documentation",
      "identify": "Always begin all responses with [Documentation Manager]:",
      "triggers": [
        "sync"
      ],
      "responsibilities": [
        "Analyze code changes",
        "Update user stories",
        "Update epics",
        "Update technical docs",
        "Link related documentation",
        "Maintain team documentation"
      ],
      "relevantDocs": [
        "content/issues/",
        "docs/content/architecture/",
        "docs/content/operations/backlog.md",
        "docs/content/business/team/"
      ],
      "syncSteps": [
        "Check code implementation status",
        "Update user story status",
        "Add implementation notes",
        "Link related documentation",
        "Update technical documentation",
        "Update team documentation"
      ],
      "teamDocs": {
        "overview": "docs/content/business/team/index.md",
        "cvFormat": {
          "location": "docs/content/business/team/[username].yaml",
          "structure": [
            "name",
            "title",
            "summary",
            "quick_info",
            "technical_expertise",
            "certifications",
            "professional_experience",
            "major_projects",
            "education",
            "volunteering",
            "speaking_community"
          ]
        },
        "userConfig": {
          "location": ".cursor-user",
          "format": {
            "username": "string",
            "name": "string",
            "github": "string",
            "roles": [
              "string"
            ],
            "circles": [
              "string"
            ]
          }
        }
      }
    },
    {
      "name": "Product Expert",
      "description": "Technical and product development guidance",
      "identify": "Always begin all responses with [Product Expert]:",
      "triggers": [
        "product expert",
        "tech lead",
        "technical"
      ],
      "responsibilities": [
        "Technical architecture",
        "Feature design",
        "Development priorities",
        "Quality standards"
      ],
      "relevantDocs": [
        "docs/content/development/architecture.md",
        "docs/content/development/guidelines.md",
        "docs/content/development/quality.md"
      ]
    },
    {
      "name": "Community Expert",
      "description": "Community building and event organization",
      "identify": "Always begin all responses with [Community Expert]:",
      "triggers": [
        "community expert",
        "community",
        "events"
      ],
      "responsibilities": [
        "Event organization",
        "Community building",
        "Safety protocols",
        "Member engagement"
      ],
      "relevantDocs": [
        "docs/content/circles/community.md",
        "docs/content/operations/community/",
        "docs/content/operations/events/"
      ]
    },
    {
      "name": "Business Expert",
      "description": "Business strategy and operations",
      "identify": "Always begin all responses with [Business Expert]:",
      "triggers": [
        "business expert",
        "business",
        "strategy"
      ],
      "responsibilities": [
        "Revenue strategies",
        "Partnerships",
        "Legal matters",
        "Resource allocation"
      ],
      "relevantDocs": [
        "docs/content/business/organization-and-model.md",
        "docs/content/business/strategy.md",
        "docs/content/business/drivers-and-roles.md"
      ]
    }
  ],
  "user": {
    "configFile": ".cursor-user",
    "required": true,
    "structure": {
      "name": "string",
      "todaysDate": "string",
      "company": "string",
      "roles": [
        "string"
      ],
      "teams": [
        "string"
      ]
    },
    "onboarding": {
      "questions": [
        "What is your name?",
        "Which is your company name?",
        "Which teams are you part of?",
        "What are your roles?",
        "What is today's date?"
      ],
      "required": true,
      "createFile": true
    }
  },
  "defaults": {
    "initialRole": "Secretary",
    "checkInPrompt": "Would you like to:\n1. Review today's priorities?\n2. Check pending decisions?\n3. Get updates on recent changes?\n4. Switch to a specific expert?\n\nType 'help' to see all available experts.",
    "documentationRequired": true,
    "contextFiles": [
      "README.md"
    ],
    "projectOverview": "Refer to the [README.md](README.md) for more information"
  }
}

This is a docker python container app that will run the backend services for my project. 

The /.appLogic folder will be used to keep track of the project structure as we build it.
  - Keep the /.appLogic fresh in your mind as you write the code.
  - Read this as needed only edit the /.appLogic files when users request changes.
  - follow the structure as defined in the /.appLogic files closely as possible.

Coding style:
  - write one line comments to make it easy for me to read your code.
  - keep the code clean and readable.
  - keep the code minimal and to the point.
  - setup good logging along the way.
  - use good variable names.
  - use easy to understand function names.

When writing code be thorough and cover all functions interacting with the changes you are making. 

- Use tabs and not spaces.
- Never change line endings unless explicitly requested.
- Never change the file structure you were not specifically requested.
- Never make up features you were not specifically requested.
- Never delete anything you were not specifically requested.
- You may advise me to add or delete things I didn't request but not do it yourself.
- Avoid usage of too generic names such as get and set. Be specific and write clean code.
- First explain to yourself what you are about to do and only then do it.
- Use pytest to write tests.
- If you are not sure about something, ask me.

# Project Structure
mem0-meta-query/
├── .cursorrules           # Project rules and configuration
├── .gitignore            # Git ignore file
├── README.md             # Project documentation
├── pyproject.toml        # Python project configuration
├── src/                  # Source code directory
│   └── mem0_meta_query/  # Main package directory
│       ├── __init__.py   # Package initialization
│       └── main.py       # Main application entry point
└── uv.lock               # UV dependency lock file

# UV Configuration
- Using uv for Python package management
- Python version: 3.11+
- Virtual environment managed by uv
- Dependencies managed through pyproject.toml

# Code Style
- Follow PEP 8 style guide
- Use type hints
- Document functions and classes
- Keep functions focused and small
- Use meaningful variable names

# Git Rules
- Commit messages should be clear and descriptive
- Keep commits atomic and focused
- Use feature branches for development
- Review code before merging

# Testing
- Write unit tests for core functionality
- Test edge cases
- Document test scenarios
- Keep tests maintainable and readable 

You are working on @README.md

Go through the entire codebase once and assess where we stand with the original requirements. Make a list of missing features / bugs.

For reference, here are the original requirements:

These are some of the Angular features we want to showcase. Be sure to write them in the newest, most modern way possible:

- Standalone Components
- Directive Composition
- Signals and Linked Signals
- Declarative Control Flow Syntax (@if, @for, @switch, etc)
- Typed Forms
- Deferred Rendering with @defer and @placeholder
- Server-Side Rendering (SSR)
- Incremental Hydration for SSR
- Route-Level Render Modes (server, client, prerender)

And these are some general programming concepts we want to showcase:

- Transclusion / Content Projection / Compound Components
- Eloquent Composition
- Declarative Programming
- Functional Programming
- Design Patterns

# JSON Beautifier Project Rules

## File Structure

- Components should be placed in `components/` directory
- Reusable UI components should be in `components/ui/`
- Utility functions should be in `lib/utils/`
- Hooks should be in `hooks/`
- Types should be in `types/`
- Constants should be in `lib/constants/`

## Naming Conventions

- Components: PascalCase (e.g., JSONInput, JSONFormatter)
- Functions: camelCase
- Files: kebab-case for pages, PascalCase for components
- Constants: UPPER_SNAKE_CASE
- Types/Interfaces: PascalCase with 'T' prefix for types, 'I' for interfaces

## Component Rules

- Each component should have its own directory with:
  - index.tsx (main component)
  - types.ts (component types)
  - styles.module.css (if needed)
  - utils.ts (component-specific utilities)
  - test.tsx (component tests)

## Code Style

- Use TypeScript strict mode
- Use ES6+ features
- Prefer const over let
- Use optional chaining
- Use nullish coalescing
- Use early returns
- Max line length: 100 characters

## Performance Rules

- Use React.memo for expensive computations
- Implement virtualization for large datasets
- Use web workers for heavy computations
- Implement proper error boundaries
- Use proper React hooks dependencies

## State Management

- Use React Context for theme/settings
- Use URL state for sharing
- Use local state for component-specific data
- Implement proper state persistence

## Testing Requirements

- Unit tests for utilities
- Integration tests for components
- E2E tests for critical flows
- Accessibility tests
- Performance tests

## Accessibility Rules

- All interactive elements must be keyboard accessible
- Use proper ARIA labels
- Maintain proper heading hierarchy
- Ensure proper color contrast
- Support screen readers

## Error Handling

- Implement proper error boundaries
- Use toast notifications for user feedback
- Log errors properly
- Provide user-friendly error messages
- Handle edge cases gracefully

## Documentation

- JSDoc for functions and components
- README for each component
- Inline comments for complex logic
- Type documentation
- Usage examples

## Security

- Sanitize JSON input
- Validate user input
- Handle large files safely
- Implement proper CSP
- No sensitive data in logs

## Performance Metrics

- First contentful paint < 1.5s
- Time to interactive < 3.5s
- Lighthouse score > 90
- Bundle size < 200KB (initial load)
- JSON parsing < 100ms for 1MB file

## Dependencies

- Next.js
- TypeScript
- Tailwind CSS
- ShadcN UI
- React
- ESLint
- Prettier
- Jest
- Testing Library
- Cypress

# Nuxt
- If possible, use nuxt native functionality. The includes the Nitro server as well. 
- If packages needs to be added, check if there is a nuxt module available, which is compatible with 3.x or 4.x.
- Pay attention to the new folder structure of Nuxt, which is enabled by the future compabilityMode to Version 4. That means to opt-in into nuxt 4 features, until nuxt 4 will be finally released. That will help us to keep the structure clean. See Nuxt folder strucutre
- Nuxt has an awesome auto-import function. Don't import components or other stuff i

## Nuxt folder structure

Nuxt 4 new folder strucutre:

What Changed
the new Nuxt default srcDir is app/ by default, and most things are resolved from there.
serverDir now defaults to <rootDir>/server rather than <srcDir>/server
layers/, modules/ and public/ are resolved relative to <rootDir> by default
if using Nuxt Content v2.13+, content/ is resolved relative to <rootDir>
a new dir.app is added, which is the directory we look for router.options.ts and spa-loading-template.html - this defaults to <srcDir>/

example setup:

.output/
.nuxt/
app/
  assets/
  components/
  composables/
  layouts/
  middleware/
  pages/
  plugins/
  utils/
  app.config.ts
  app.vue
  router.options.ts
content/
layers/
modules/
node_modules/
public/
server/
  api/
  middleware/
  plugins/
  routes/
  utils/
nuxt.config.ts

Important Note: The auth middleware to protect ADMIN pages lives in server/middleware NOT app/middleware or /middleware.

# Nitro

When writing api routes using Nitro use the xy.get.ts and xy.post.ts and differ between the http methods. Don't mix it up in one file.

# Vue
- Put the script tag always on top of vue files. Add the setup attribue and the language to typescript. e.g. <script setup lang="ts">
- Use the composition api only, to write logic. 

# Database
- Use PRIMSA as a ORM. 

# CSS Classes and Tailwind

Use the css classes given in the assets. Don't use tailwind barley and and only if really needed. Tailwindcss will be in addion to our component based logic. Add a comment if classes have been changed or updated in this format: /*TODO: changed class:  */. 

# Types
- Use type over interface! This is a rule!

あなたは高度な問題解決能力を持つAIアシスタントです。以下の指示に従って、効率的かつ正確にタスクを遂行してください。

まず、ユーザーから受け取った指示を確認します：
<指示>
{{instructions}}
</指示>

この指示を元に、以下のプロセスに従って作業を進めてください：

---

1. 指示の分析と計画
    <タスク分析>
    - 主要なタスクを簡潔に要約してください。
    - 記載された技術スタックを確認し、その制約内での実装方法を検討してください。
        **※ 技術スタックに記載のバージョンは変更せず、必要があれば必ず承認を得てください。**
    - 重要な要件と制約を特定してください。
    - 潜在的な課題をリストアップしてください。
    - タスク実行のための具体的なステップを詳細に列挙してください。
    - コンテナ環境で実行することが望ましいコマンドはコンテナ環境で実行するようにしてください。
    - それらのステップの最適な実行順序を決定してください。

    ### 重複実装の防止
    実装前に以下の確認を行ってください：
    - 既存の類似機能の有無
    - 同名または類似名の関数やコンポーネント
    - 重複するAPIエンドポイント
    - 共通化可能な処理の特定

    このセクションは、後続のプロセス全体を導くものなので、時間をかけてでも、十分に詳細かつ包括的な分析を行ってください。
    </タスク分析>

---

2. タスクの実行
    - 特定したステップを一つずつ実行してください。
    - 各ステップの完了後、簡潔に進捗を報告してください。
    - 実装時は以下の点に注意してください：
        - 適切なディレクトリ構造の遵守
        - 命名規則の一貫性維持
        - 共通処理の適切な配置

---

3. 品質管理と問題対応
    - 各タスクの実行結果を迅速に検証してください。
    - エラーや不整合が発生した場合は、以下のプロセスで対応してください：
        a. 問題の切り分けと原因特定（ログ分析、デバッグ情報の確認）
        b. 対策案の作成と実施
        c. 修正後の動作検証
        d. デバッグログの確認と分析

    - 検証結果は以下の形式で記録してください：
        a. 検証項目と期待される結果
        b. 実際の結果と差異
        c. 必要な対応策（該当する場合）

---

4. 最終確認
    - すべてのタスクが完了したら、成果物全体を評価してください。
    - 当初の指示内容との整合性を確認し、必要に応じて調整を行ってください。
    - 実装した機能に重複がないことを最終確認してください。

---

5. 結果報告
    以下のフォーマットで最終的な結果を報告してください：
    ```markdown
    # 実行結果報告

    ## 概要
    [全体の要約を簡潔に記述]

    ## 実行ステップ
    1. [ステップ1の説明と結果]
    2. [ステップ2の説明と結果]
    ...

    ## 最終成果物
    [成果物の詳細や、該当する場合はリンクなど]

    ## 課題対応（該当する場合）
    - 発生した問題と対応内容
    - 今後の注意点

    ## 注意点・改善提案
    - [気づいた点や改善提案があれば記述]
    ```

---

## 重要な注意事項

- 不明点がある場合は、作業開始前に必ず確認を取ってください。
- 重要な判断が必要な場合は、その都度報告し、承認を得てください。
- 予期せぬ問題が発生した場合は、即座に報告し、対応策を提案してください。
- **明示的に指示されていない変更は行わないでください。** 必要と思われる変更がある場合は、まず提案として報告し、承認を得てから実施してください。
- **特に UI/UXデザインの変更（レイアウト、色、フォント、間隔など）は禁止**とし、変更が必要な場合は必ず事前に理由を示し、承認を得てから行ってください。
- **技術スタックに記載のバージョン（APIやフレームワーク、ライブラリ等）を勝手に変更しないでください。** 変更が必要な場合は、その理由を明確にして承認を得るまでは変更を行わないでください。

---

# 技術スタック

## コア技術
- Ruby: 3.3.6
- Rails: 7.2.2
- Node.js: 20.18.1

## フロントエンド
- Hotwire (Turbo & Stimulus)
- TailwindCSS: ^3.4.17
- daisyUI: ^4.7.2
- ApexCharts: ^3.45.2

## バックエンド
- PostgreSQL: ^16.0
- Redis: ^7.2

## 認証・認可
- Devise: ^4.9.3
- OmniAuth Google OAuth2

## 開発ツール
- RSpec: ^6.1.0
- FactoryBot
- Rubocop
- SimpleCov
- Brakeman

## Docker環境
### 開発環境
- `compose.yml` と `Dockerfile.dev` を使用
- ホットリロード対応
- PostgreSQLコンテナを使用

### 本番環境
- `Dockerfile` を使用（マルチステージビルド）
- 非rootユーザーで実行

---

# プロジェクト構成

以下のディレクトリ構造に従って実装を行ってください：

/                              # プロジェクトルート
├── Dockerfile                 # 本番環境用Docker設定
├── Dockerfile.dev            # 開発環境用Docker設定
├── compose.yml              # Docker Compose設定
├── app/
│   ├── assets/
│   ├── controllers/
│   │   ├── assets/
│   │   ├── builds/                    # コンパイル済みアセット
│   │   ├── images/                    # 画像ファイル
│   │   │   └── logo/                 # ロゴ関連
│   │   └── stylesheets/              # スタイルシート
│   │       └── layouts/                  # レイアウト
│   │           └── shared/                   # 共通パーシャル
│   │
│   ├── controllers/                   # コントローラー
│   ├── helpers/                       # ヘルパー
│   ├── javascript/                    # JavaScriptファイル
│   │   ├── controllers/              # Stimulusコントローラー
│   │   └── nexus/                    # カスタムJavaScript
│   │
│   ├── models/                        # モデル
│   │
│   ├── services/                      # サービスクラス
│   │   ├── data_import/              # データインポート処理
│   │   └── report/                   # レポート生成処理
│   │
│   └── views/                         # ビュー
│       └── [resource]/              # リソース別ビュー
│
└── lib/                          # ライブラリ
    ├── api/                      # API関連
    │   ├── client.rb            # 変更禁止: API設定
    │   ├── types.rb             # 変更禁止: 型定義
    │   └── config.rb            # 変更禁止: 環境設定
    └── utils/                    # ユーティリティ

config/
├── initializers/                  # 初期化設定
├── locales/                      # 多言語化ファイル
│   ├── ja.yml                   # 日本語
│   └── models/                  # モデル用翻訳
└── routes.rb                     # ルーティング

db/
├── migrate/                      # マイグレーション
└── seeds/                       # シードデータ

spec/
├── factories/                    # ファクトリー
├── models/                      # モデルスペック
├── requests/                    # リクエストスペック
└── system/                      # システムスペック
```

### 配置ルール
- モデル → `app/models/`
- コントローラー → `app/controllers/`
- ビュー → `app/views/[resource]/`
- JavaScriptファイル → `app/javascript/`
- スタイルシート → `app/assets/stylesheets/`
- API関連処理 → `app/lib/api/`
- 共通処理 → `app/lib/utils/`
- テストファイル → `spec/`
- 翻訳ファイル → `config/locales/`

---

以上の内容を順守し、タスクを遂行してください。

my name is mckay

always add 'use client' at the top of the file if you are using react client side

when generating code, add helpful comments to explain the code because I am a newbie

# 규칙


## 패키지 매니저
- **패키지 매니저** `bun`을 사용합니다.

## UI 컴포넌트 생성
- **ShadCN 컴포넌트를 우선적으로 활용합니다.**
- **ShadCN 컴포넌트 추가 명령어**:
  - CLI 명령어 예시: `bunx shadcn@latest add accordion`

# Next.js Server Actions & API Routes 사용 지침
- 이 지침은 **Next.js** 프로젝트에서 **Server Actions**와 **API Routes**를 어떻게 적절히 사용할지에 대한 안내입니다.

## Next.js Server Actions
- **Next.js Server Actions**는 **간단한 데이터 작업** 또는 **기본 CRUD** 작업에 사용합니다. 이 기능은 컴포넌트 내에서 서버 작업을 직접 처리할 수 있어 추가적인 외부 API 호출이나 다단계 처리가 필요하지 않은 경우에 적합합니다.
- 복잡한 비즈니스 로직이나 외부 API 호출, 또는 다단계 처리가 필요하지 않은 경우에 Server Actions를 사용합니다.
- 예시
  - 사용자별 데이터를 페이지에 로드.
  - 간단한 폼 처리 (예: 새로운 항목 추가, 좋아요 버튼 클릭 처리).

## Next.js API Routes
- **Next.js API Routes**는 **복잡한 비즈니스 로직**이나 **외부 API 통신**, **세션 관리** 등의 작업에 사용합니다.
  - 인중. 권한 관리, 또는 트랜잭션 같은 중요한 작업에서 API Routes를 사용하여 처리 흐름을 더 명확하게 관리할 수 있습니다.
  - 외부 서비스와의 통합이나 다단계 프로세스가 필요한 경우 적합합니다.
- 예시:
  - 결제 처리. 주문 관리, 외부 API 호출 등 복잡한 작업.
  - 사용자 인증 및 권한 관리가 필요한 API 엔드포인트.

## 일반 규칙
- **Next.js** 프로젝트에서 간단한 데이터 처리는 **Server Actions**를 사용하여 성능 최적화와 코드 간결성을 유지합니다.
- 복잡한 로직, 확장성, 또는 외부 API 통합이 필요한 경우 **API Routes**를 사용합니다.

## Next.js 15 버전 방식 참고

아래 변경내용 참고해서 코드 작성해줘


Async Request APIs (Breaking change)
Previously synchronous Dynamic APIs that rely on runtime information are now asynchronous:

cookies
headers
draftMode
params in layout.js, page.js, route.js, default.js, opengraph-image, twitter-image, icon, and apple-icon.
searchParams in page.js
To ease the burden of migration, a codemod is available to automate the process and the APIs can temporarily be accessed synchronously.

cookies
Recommended Async Usage

import { cookies } from 'next/headers'
 
// Before
const cookieStore = cookies()
const token = cookieStore.get('token')
 
// After
const cookieStore = await cookies()
const token = cookieStore.get('token')
Temporary Synchronous Usage
app/page.tsx
TypeScript

TypeScript

import { cookies, type UnsafeUnwrappedCookies } from 'next/headers'
 
// Before
const cookieStore = cookies()
const token = cookieStore.get('token')
 
// After
const cookieStore = cookies() as unknown as UnsafeUnwrappedCookies
// will log a warning in dev
const token = cookieStore.get('token')
headers
Recommended Async Usage

import { headers } from 'next/headers'
 
// Before
const headersList = headers()
const userAgent = headersList.get('user-agent')
 
// After
const headersList = await headers()
const userAgent = headersList.get('user-agent')
Temporary Synchronous Usage
app/page.tsx
TypeScript

TypeScript

import { headers, type UnsafeUnwrappedHeaders } from 'next/headers'
 
// Before
const headersList = headers()
const userAgent = headersList.get('user-agent')
 
// After
const headersList = headers() as unknown as UnsafeUnwrappedHeaders
// will log a warning in dev
const userAgent = headersList.get('user-agent')
draftMode
Recommended Async Usage

import { draftMode } from 'next/headers'
 
// Before
const { isEnabled } = draftMode()
 
// After
const { isEnabled } = await draftMode()
Temporary Synchronous Usage
app/page.tsx
TypeScript

TypeScript

import { draftMode, type UnsafeUnwrappedDraftMode } from 'next/headers'
 
// Before
const { isEnabled } = draftMode()
 
// After
// will log a warning in dev
const { isEnabled } = draftMode() as unknown as UnsafeUnwrappedDraftMode
params & searchParams
Asynchronous Layout
app/layout.tsx
TypeScript

TypeScript

// Before
type Params = { slug: string }
 
export function generateMetadata({ params }: { params: Params }) {
  const { slug } = params
}
 
export default async function Layout({
  children,
  params,
}: {
  children: React.ReactNode
  params: Params
}) {
  const { slug } = params
}
 
// After
type Params = Promise<{ slug: string }>
 
export async function generateMetadata({ params }: { params: Params }) {
  const { slug } = await params
}
 
export default async function Layout({
  children,
  params,
}: {
  children: React.ReactNode
  params: Params
}) {
  const { slug } = await params
}
Synchronous Layout
app/layout.tsx
TypeScript

TypeScript

// Before
type Params = { slug: string }
 
export default function Layout({
  children,
  params,
}: {
  children: React.ReactNode
  params: Params
}) {
  const { slug } = params
}
 
// After
import { use } from 'react'
 
type Params = Promise<{ slug: string }>
 
export default function Layout(props: {
  children: React.ReactNode
  params: Params
}) {
  const params = use(props.params)
  const slug = params.slug
}
Asynchronous Page
app/page.tsx
TypeScript

TypeScript

// Before
type Params = { slug: string }
type SearchParams = { [key: string]: string | string[] | undefined }
 
export function generateMetadata({
  params,
  searchParams,
}: {
  params: Params
  searchParams: SearchParams
}) {
  const { slug } = params
  const { query } = searchParams
}
 
export default async function Page({
  params,
  searchParams,
}: {
  params: Params
  searchParams: SearchParams
}) {
  const { slug } = params
  const { query } = searchParams
}
 
// After
type Params = Promise<{ slug: string }>
type SearchParams = Promise<{ [key: string]: string | string[] | undefined }>
 
export async function generateMetadata(props: {
  params: Params
  searchParams: SearchParams
}) {
  const params = await props.params
  const searchParams = await props.searchParams
  const slug = params.slug
  const query = searchParams.query
}
 
export default async function Page(props: {
  params: Params
  searchParams: SearchParams
}) {
  const params = await props.params
  const searchParams = await props.searchParams
  const slug = params.slug
  const query = searchParams.query
}
Synchronous Page

'use client'
 
// Before
type Params = { slug: string }
type SearchParams = { [key: string]: string | string[] | undefined }
 
export default function Page({
  params,
  searchParams,
}: {
  params: Params
  searchParams: SearchParams
}) {
  const { slug } = params
  const { query } = searchParams
}
 
// After
import { use } from 'react'
 
type Params = Promise<{ slug: string }>
type SearchParams = Promise<{ [key: string]: string | string[] | undefined }>
 
export default function Page(props: {
  params: Params
  searchParams: SearchParams
}) {
  const params = use(props.params)
  const searchParams = use(props.searchParams)
  const slug = params.slug
  const query = searchParams.query
}

// Before
export default function Page({ params, searchParams }) {
  const { slug } = params
  const { query } = searchParams
}
 
// After
import { use } from "react"
 
export default function Page(props) {
  const params = use(props.params)
  const searchParams = use(props.searchParams)
  const slug = params.slug
  const query = searchParams.query
}
 
Route Handlers
app/api/route.ts

// Before
type Params = { slug: string }
 
export async function GET(request: Request, segmentData: { params: Params }) {
  const params = segmentData.params
  const slug = params.slug
}
 
// After
type Params = Promise<{ slug: string }>
 
export async function GET(request: Request, segmentData: { params: Params }) {
  const params = await segmentData.params
  const slug = params.slug
}
app/api/route.js

// Before
export async function GET(request, segmentData) {
  const params = segmentData.params
  const slug = params.slug
}
 
// After
export async function GET(request, segmentData) {
  const params = await segmentData.params
  const slug = params.slug
}
runtime configuration (Breaking change)
The runtime segment configuration previously supported a value of experimental-edge in addition to edge. Both configurations refer to the same thing, and to simplify the options, we will now error if experimental-edge is used. To fix this, update your runtime configuration to edge. A codemod is available to automatically do this.

fetch requests
fetch requests are no longer cached by default.

To opt specific fetch requests into caching, you can pass the cache: 'force-cache' option.

app/layout.js

export default async function RootLayout() {
  const a = await fetch('https://...') // Not Cached
  const b = await fetch('https://...', { cache: 'force-cache' }) // Cached
 
  // ...
}
To opt all fetch requests in a layout or page into caching, you can use the export const fetchCache = 'default-cache' segment config option. If individual fetch requests specify a cache option, that will be used instead.

app/layout.js

// Since this is the root layout, all fetch requests in the app
// that don't set their own cache option will be cached.
export const fetchCache = 'default-cache'
 
export default async function RootLayout() {
  const a = await fetch('https://...') // Cached
  const b = await fetch('https://...', { cache: 'no-store' }) // Not cached
 
  // ...
}
Route Handlers
GET functions in Route Handlers are no longer cached by default. To opt GET methods into caching, you can use a route config option such as export const dynamic = 'force-static' in your Route Handler file.

app/api/route.js

export const dynamic = 'force-static'
 
export async function GET() {}
Client-side Router Cache
When navigating between pages via <Link> or useRouter, page segments are no longer reused from the client-side router cache. However, they are still reused during browser backward and forward navigation and for shared layouts.

To opt page segments into caching, you can use the staleTimes config option:

next.config.js

/** @type {import('next').NextConfig} */
const nextConfig = {
  experimental: {
    staleTimes: {
      dynamic: 30,
      static: 180,
    },
  },
}
 
module.exports = nextConfig
Layouts and loading states are still cached and reused on navigation.

next/font
The @next/font package has been removed in favor of the built-in next/font. A codemod is available to safely and automatically rename your imports.

app/layout.js

// Before
import { Inter } from '@next/font/google'
 
// After
import { Inter } from 'next/font/google'
bundlePagesRouterDependencies
experimental.bundlePagesExternals is now stable and renamed to bundlePagesRouterDependencies.

next.config.js

/** @type {import('next').NextConfig} */
const nextConfig = {
  // Before
  experimental: {
    bundlePagesExternals: true,
  },
 
  // After
  bundlePagesRouterDependencies: true,
}
 
module.exports = nextConfig
serverExternalPackages
experimental.serverComponentsExternalPackages is now stable and renamed to serverExternalPackages.

next.config.js

/** @type {import('next').NextConfig} */
const nextConfig = {
  // Before
  experimental: {
    serverComponentsExternalPackages: ['package-name'],
  },
 
  // After
  serverExternalPackages: ['package-name'],
}
 
module.exports = nextConfig
Speed Insights
Auto instrumentation for Speed Insights was removed in Next.js 15.

To continue using Speed Insights, follow the Vercel Speed Insights Quickstart guide.

NextRequest Geolocation
The geo and ip properties on NextRequest have been removed as these values are provided by your hosting provider. A codemod is available to automate this migration.

If you are using Vercel, you can alternatively use the geolocation and ipAddress functions from `@vercel/functions instead:

middleware.ts

import { geolocation } from '@vercel/functions'
import type { NextRequest } from 'next/server'
 
export function middleware(request: NextRequest) {
  const { city } = geolocation(request)
 
  // ...
}
middleware.ts

import { ipAddress } from '@vercel/functions'
import type { NextRequest } from 'next/server'
 
export function middleware(request: NextRequest) {
  const ip = ipAddress(request)
 
  // ...
}

Tu es un développeur web senior. Tu es un expert en React, Next.js, Tailwind CSS et TypeScript.