@wondev/dotenv-example 1.0.1 → 1.0.3

package/.cursor/rules/web/nextjs-convention.mdc

@@ -1,237 +0,0 @@
----
-description: This rule defines unified conventions and best practices for building scalable, maintainable, and consistent fullstack applications with Next.js, covering file naming, directory structure, component architecture, and technology stack guidelines based on React 19 and Next.js 15.
-globs: **/*.js,**/*.jsx,**/*.ts,**/*.tsx
-alwaysApply: false
----
-# NextJS Convention
-
-## Package Manager
-
-pnpm을 사용합니다.
-만약 pnpm 에러가 난다면 `npm install -g pnpm` 명령어로 pnpm을 설치합니다.
-
-## File Name Convention
-
-- 모든 파일명은 `kebab-case` 로 작성합니다.
-- `not-found.tsx`, `mdx-components.tsx` 처럼, 최대한 간결하게 하되, 단어 사이는 하이픈으로 연결합니다.
-
-## Function/Variable Convention
-
-- `camelCase` 로 작성합니다.
-- TypeScript 타입은 반드시 정의해야 합니다.
-
-## Component Convention
-
-- Component 명은 `PascalCase` 로 작성합니다. (Component 파일명도 예외없이 `kebab-case`로 작성합니다)
-- Component는 재사용 가능하도록 설계해야 합니다.
-
-## Directory Convention
-
-`app` 외부에 프로젝트 파일 저장하는 방법을 사용합니다.
-
-### src/app
-
-- 라우팅 용으로 사용한다. (라우팅과 관련된 파일만 넣어놓는다)
-- e.g. `page.tsx`, `layout.tsx`, `opengraph-image.tsx`
-
-### src/actions
-
-- 무조건 API 대신 Server Action을 사용한다. 불가피한 경우에만 API를 사용한다.
-- NextJS Server Action 파일들을 넣어놓는다.
-
-### src/components
-
-- 여러 페이지에서 공통으로 사용할 컴포넌트
-- Button, Loading...
-
-### src/constants
-
-- 공통으로 사용 할 상수
-
-### src/hooks
-
-- 페이지 곳곳에서 사용되는 공통 훅
-
-### src/utils
-
-- 공통으로 사용되는 유틸 함수
-- e.g. supabase/client.ts, supabase/server.ts ...
-
-### src/states
-
-- props drilling을 막기 위한 전역 state를 모아둔다.
-- 전역 상태관리는 최대한 남발하지 않으며 jotai를 사용한다.
-
-### src/types
-
-- 각종 타입 스크립트의 정의가 들어가는 곳
-
-### tests
-
-- 테스트 파일을 모아두는 곳
-
-## Package Convention
-
-### Vitest
-
-```sh
-pnpm install -D vitest @vitejs/plugin-react jsdom @testing-library/react @testing-library/dom vite-tsconfig-paths
-```
-
-`vitest.config.mts`
-```json
-import { defineConfig } from 'vitest/config'
-import react from '@vitejs/plugin-react'
-import tsconfigPaths from 'vite-tsconfig-paths'
-
-export default defineConfig({
-  plugins: [tsconfigPaths(), react()],
-  test: {
-    environment: 'jsdom',
-  },
-})
-```
-
-`package.json`
-```json
-{
-  "scripts": {
-    "dev": "next dev",
-    "build": "next build",
-    "start": "next start",
-    "test": "vitest" // 추가
-  }
-}
-```
-
-테스트 예시: `__tests__/page.test.tsx`
-```tsx
-import { expect, test } from 'vitest'
-import { render, screen } from '@testing-library/react'
-import Page from '../app/page'
-
-test('Page', () => {
-  render(<Page />)
-  expect(screen.getByRole('heading', { level: 1, name: 'Home' })).toBeDefined()
-})
-```
-
-### TailwindCSS
-
-- 모든 스타일은 TailwindCSS를 사용해야 합니다.
-- TailwindCSS v4 버전을 사용합니다.
-  - 그러므로 `tailwind.config.js`, `tailwind.config.ts` 파일은 사용하지 않고 `globals.css` 파일만을 사용합니다.
-
-### ShadCN Component
-
-- 모든 UI 컴포넌트는 ShadCN을 사용해야 합니다.
-- 컴포넌트 사용 전 설치 여부를 확인해야 합니다: `/component/ui` 디렉토리 체크
-- 컴포넌트 설치 명령어를 사용해야 합니다: `pnpx shadcn@latest add [component-name]`
-
-### lucide-react
-
-- 모든 아이콘은 lucide-react를 사용해야 합니다.
-- 아이콘 임포트 방법: `import { IconName } from 'lucide-react';`
-- 예시: `import { Menu, X } from 'lucide-react';`
-
-### Jotai
-
-- 전역 상태관리는 Jotai를 사용해야 합니다.
-
-### React Query
-
-- 데이터 패칭은 React Query를 사용해야 합니다.
-
-### Supabase
-
-- 데이터베이스는 Supabase를 사용해야 하며 `@supabase/supabase-js`를 사용해야 합니다.
-- 사용자 인증은 Supabase Auth를 사용해야 하며 `@supabase/ssr`를 사용해야 합니다.
-- 클라이언트 파일은 `utils/supabase` 폴더에 넣어야 합니다.
-
-## Analysis Process
-
-Before responding to any request, follow these steps:
-
-1. Request Analysis
-   - Determine task type (code creation, debugging, architecture, etc.)
-   - Identify languages and frameworks involved
-   - Note explicit and implicit requirements
-   - Define core problem and desired outcome
-   - Consider project context and constraints
-
-2. Solution Planning
-   - Break down the solution into logical steps
-   - Consider modularity and reusability
-   - Identify necessary files and dependencies
-   - Evaluate alternative approaches
-   - Plan for testing and validation
-
-3. Implementation Strategy
-   - Choose appropriate design patterns
-   - Consider performance implications
-   - Plan for error handling and edge cases
-   - Ensure accessibility compliance
-   - Verify best practices alignment
-
-## Feature Implementation Workflow
-
-기능을 구현할 때는 **반드시** 다음의 조건과 단계를 따릅니다:
-1.  **계획 수립 및 검토:**
-   - 요구사항 분석을 바탕으로 구체적인 구현 계획을 세웁니다.
-   - 수립된 계획을 사용자에게 제시하고, 진행 전에 반드시 검토와 승인을 받습니다.
-2.  **단계적 구현 및 검증:**
-   - 기능 구현 과정을 논리적인 작은 단위로 세분화하여 단계적으로 진행합니다.
-   - 각 단계의 핵심 로직에는 서버 및 클라이언트 환경 모두에 로그(예: `console.group`, `console.log`)를 추가합니다.
-       - 로그는 기능의 정상 작동 여부를 확인하고, 잠재적인 문제를 조기에 발견하여 디버깅하는 데 활용됩니다.
-       - 구현이 완료되고 안정화된 후에는 디버깅 목적의 로그는 제거하거나, 필요한 경우 최소한으로 유지하는 것을 고려합니다.
-   - 각 단계 구현 후에는 충분한 테스트와 검증을 통해 의도한 대로 작동하는지 확인합니다.
-
-## Code Style and Structure
-
-### General Principles
-
-- Write concise, readable TypeScript code
-- Use functional and declarative programming patterns
-- Follow DRY (Don't Repeat Yourself) principle
-- Implement early returns for better readability
-- Structure components logically: exports, subcomponents, helpers, types
-
-### Naming Conventions
-
-- Use descriptive names with auxiliary verbs (isLoading, hasError)
-- Prefix event handlers with "handle" (handleClick, handleSubmit)
-- Use lowercase with dashes for directories (components/auth-wizard)
-- Favor named exports for components
-
-### TypeScript Usage
-
-- Use TypeScript for all code
-- Prefer interfaces over types
-- Avoid enums; use const maps instead
-- Implement proper type safety and inference
-- Use `satisfies` operator for type validation
-
-## React 19 and Next.js 15 Best Practices
-
-### Component Architecture
-
-- Favor React Server Components (RSC) where possible
-- Minimize 'use client' directives
-- Implement proper error boundaries
-- Use Suspense for async operations
-- Optimize for performance and Web Vitals
-
-### Async Request APIs
-
-```typescript
-// Always use async versions of runtime APIs
-const cookieStore = await cookies()
-const headersList = await headers()
-const { isEnabled } = await draftMode()
-
-// Handle async params in layouts/pages
-const params = await props.params
-const searchParams = await props.searchParams
-```
-
-<!-- https://github.com/PatrickJS/awesome-cursorrules/blob/main/rules/nextjs15-react19-vercelai-tailwind-cursorrules-prompt-file/.cursorrules -->

package/.cursor/rules/web/playwright-test-guide.mdc

@@ -1,176 +0,0 @@
----
-description: Playwright 테스트 작성 가이드
-globs:
-alwaysApply: false
----
-
-# Playwright 테스트 작성 가이드
-
-## 1. 프로젝트 구조
-
-```
-tests/
-├── e2e/                 # E2E 테스트
-├── integration/         # 통합 테스트
-├── fixtures/            # 테스트 데이터
-```
-
-## 2. 테스트 파일 작성 규칙
-
-### 파일 명명 규칙
-
-- 테스트 파일은 .spec.ts 확장자 사용
-- 파일명은 하이픈(-)으로 구분하고 테스트 대상을 명확히 표현
-
-```
-login.spec.ts
-create-post.spec.ts
-user-profile.spec.ts
-```
-
-### 기본 테스트 구조
-
-```ts
-import { test, expect } from '@playwright/test';
-import { TEST_USERS } from '../fixtures/users';
-
-test.describe('인증 및 로그인 테스트', () => {
-  test.beforeEach(async ({ page }) => {
-    await page.goto('/login');
-  });
-
-  test('유효한 자격증명으로 로그인 시 대시보드로 이동', async ({ page }) => {
-    // 테스트 로직
-  });
-});
-```
-
-## 3. 테스트 케이스 작성 규칙
-
-### 테스트 설명
-
-```ts
-// ❌ 잘못된 예
-test('login test', async ({ page }) => {});
-
-// ✅ 좋은 예
-test('유효한 이메일과 비밀번호로 로그인 시 대시보드로 이동해야 함', async ({
-  page,
-}) => {});
-```
-
-### 테스트 단계 구분
-
-```ts
-test('상품 구매 프로세스', async ({ page }) => {
-  await test.step('상품 페이지 진입', async () => {
-    await page.goto('/products/1');
-    await expect(page).toHaveURL('/products/1');
-  });
-
-  await test.step('장바구니에 추가', async () => {
-    await page.getByRole('button', { name: '장바구니 추가' }).click();
-    await expect(page.getByRole('alert')).toHaveText(
-      '장바구니에 추가되었습니다',
-    );
-  });
-});
-```
-
-## 4. Locator 전략
-
-### 우선순위
-
-```ts
-// 1. Role과 접근성 속성 (최우선)
-page.getByRole('button', { name: '로그인' });
-page.getByLabel('이메일');
-page.getByRole('textbox', { name: '비밀번호' });
-page.getByRole('heading', { name: '회원가입' });
-
-// 2. 텍스트 및 기타
-page.getByText('계정 만들기');
-page.getByPlaceholder('이메일을 입력하세요');
-
-// 3. 테스트 ID (Role과 접근성 속성으로 선택이 어려운 경우에 사용)
-// ⚠️ 사용 전 반드시 해당 요소에 data-testid 속성이 정의되어 있는지 확인
-page.getByTestId('submit-button');
-
-// 안티 패턴
-// ❌ 피해야 할 방식
-page.locator('.login-btn');
-page.locator('div > button');
-```
-
-## 5. 검증(Assertions) 가이드
-
-```ts
-// 요소 상태 검증
-await expect(page.getByRole('button')).toBeEnabled();
-await expect(page.getByRole('alert')).toBeVisible();
-
-// 텍스트 검증
-await expect(page.getByRole('heading')).toHaveText('환영합니다');
-
-// URL 검증
-await expect(page).toHaveURL(/.*dashboard/);
-
-// 다중 요소 검증
-await expect(page.getByRole('listitem')).toHaveCount(3);
-```
-
-## 6. 테스트 데이터 관리
-
-```ts
-// tests/fixtures/users.ts
-export const TEST_USERS = {
-  valid: {
-    email: 'test@example.com',
-    password: 'password123',
-  },
-  invalid: {
-    email: 'invalid@example.com',
-    password: 'wrong',
-  },
-};
-```
-
-## 7. 모킹 전략
-
-다음과 같은 경우에만 API 모킹을 사용합니다:
-
-- 외부 API 의존성이 있는 경우
-- 테스트 환경에서 실제 API가 사용 불가능한 경우
-- 특정 에러 상황 테스트가 필요한 경우
-
-```ts
-// 특정 에러 상황 테스트를 위한 모킹 예시
-test('API 에러 발생 시 에러 메시지 표시', async ({ page }) => {
-  await page.route('**/api/users', (route) => {
-    route.fulfill({
-      status: 500,
-      contentType: 'application/json',
-      body: JSON.stringify({ error: '서버 오류가 발생했습니다.' }),
-    });
-  });
-
-  await page.goto('/users');
-  await expect(page.getByRole('alert')).toHaveText('서버 오류가 발생했습니다.');
-});
-```
-
-## 8. 인증 상태 관리 (storageState)
-
-### 인증이 필요한 테스트에서 사용
-
-```typescript
-// tests/e2e/protected-route.spec.ts
-import { test } from '@playwright/test';
-
-test.use({ storageState: './tests/fixtures/auth.json' });
-
-test('인증이 필요한 페이지 접근', async ({ page }) => {
-  await page.goto('/dashboard');
-  // ... 테스트 로직
-});
-```