component-creation

Create a component directory with four files: a `.tsx` file for the component logic using `type` over `interface`, a `.module.css` file for styling with design tokens, a `.stories.tsx` file for Storybook documentation, and a `.test.tsx` file for vitest tests. This standardized structure ensures consistency across your monorepo and makes components easily testable and documented.

Use Radix UI primitives like `@radix-ui/react-dialog` for built-in accessibility, document interactive states in Storybook stories with `@testing-library/react` and `user-event`, and write vitest tests that verify component behavior and accessibility. This approach creates components that are accessible by default and thoroughly tested before reaching production.

Yes. CSS Modules integrate fully with design tokens in your component's `.module.css` file, enabling consistent styling without inline styles or utility classes. Import the styles into your `.tsx` component file and apply token-based classes to ensure design consistency across your component library.

Yes, Storybook stories are part of the standardized component structure. They serve as interactive documentation and enable story-based testing with vitest, making components easier to develop, review, and maintain while providing a living style guide for your team.

Prefer `type` aliases over `interface` declarations and avoid `React.FC` in favor of direct function declarations with explicit return types. These conventions reduce boilerplate, improve type inference, and align with modern React and TypeScript best practices enforced across the monorepo.

You'll need vitest for unit testing, `@testing-library/react` and `user-event` for testing user interactions, Storybook for interactive component documentation, and `@radix-ui/react-dialog` for accessible component primitives. These tools work together to create testable, documented, and accessible components.