|
| 1 | +# Copilot Instructions |
| 2 | + |
| 3 | +This project is a web application built with React 18, Material-UI (MUI), and GraphQL, using Yarn as the package manager and Razzle for the custom build process. Follow these guidelines to ensure consistent, high-quality code aligned with our coding standards. |
| 4 | + |
| 5 | +## Coding Standards |
| 6 | + |
| 7 | +- Use camelCase for variables, functions, and methods. |
| 8 | +- Use PascalCase for React components, classes, and enums. |
| 9 | +- Use kebab-case for new folders and files. |
| 10 | +- Use single quotes for strings. |
| 11 | +- Use 2 spaces for indentation. |
| 12 | +- Prefer arrow functions for callbacks. |
| 13 | +- Use async/await for GraphQL queries and mutations. |
| 14 | +- Use const for constants, let for reassignable variables. |
| 15 | +- Use destructuring for objects and arrays. |
| 16 | +- Use template literals for dynamic strings. |
| 17 | +- Follow SOLID principles for modular, reusable, and maintainable code. |
| 18 | +- Avoid code duplication, deeply nested statements, and hard-coded values (e.g., file paths, usernames). |
| 19 | +- Use constants or enums instead of magic numbers/strings for readability and memory efficiency. |
| 20 | + |
| 21 | +## Project Preferences |
| 22 | + |
| 23 | +- Use React with functional components and hooks. |
| 24 | +- Use Material-UI (MUI) v5 for UI components and styling: |
| 25 | + - Use the `sx` prop as the primary styling method. |
| 26 | + - Avoid `useStyles` or `makeStyles` (MUI v4 patterns). |
| 27 | + - Reference `src/theme` for custom MUI theme configurations in `sx` (e.g., `sx={{ color: theme.palette.primary.main }}`). |
| 28 | +- Use Apollo Client for GraphQL: |
| 29 | + - Write type-safe queries and mutations with generated TypeScript types. |
| 30 | + - Store queries, mutations, and fragments in `src/api`. |
| 31 | +- Use Yarn for package management: |
| 32 | + - Run `yarn add` for dependencies, checking for vulnerabilities with Snyk. |
| 33 | + - Use `yarn start`, `yarn build`, and `yarn test` for Razzle scripts. |
| 34 | +- Custom build process with Razzle: |
| 35 | + - Configure Razzle in `razzle.config.js` for build settings. |
| 36 | + - Optimize for production with code splitting and server-side rendering (SSR). |
| 37 | + - Use `src/server` for Razzle server configurations. |
| 38 | +- Use TypeScript for all code: |
| 39 | + - Enforce strict mode. |
| 40 | + - Define interfaces and types in `src/common`. |
| 41 | +- Follow folder structure: |
| 42 | + - `src/api`: GraphQL queries, mutations, Apollo Client setup, and API-related files. |
| 43 | + - `src/common`: Utility TypeScript files (types, interfaces, general-use TS). |
| 44 | + - `src/components`: Reusable React components (mostly TSX, some with GraphQL files), with subfolders. |
| 45 | + - `src/hooks`: Custom React hooks (TypeScript). |
| 46 | + - `src/scenes`: Application-specific, non-reusable components (mostly TSX, some with GraphQL files), with subfolders. |
| 47 | + - `src/server`: Razzle server configuration files. |
| 48 | + - `src/theme`: MUI theme configuration files. |
| 49 | + |
| 50 | +## Version Control |
| 51 | + |
| 52 | +- Create branches with format: `type/MondayTicketID-description` (e.g., `enhancement/1234-new-profile-page`). |
| 53 | +- Write commit messages: |
| 54 | + - First line: `[TicketID] - [Short Title] - Imperative verb` (e.g., `0654 - IRP - Remove/move Impact Report Date`). |
| 55 | + - Optional body: Briefly explain why the change is needed or the problem addressed. |
| 56 | +- Create PRs for single, specific changes (one user story per PR unless deployable in isolation): |
| 57 | + - Link the Monday ticket in the PR description. |
| 58 | + - Break changes into bite-sized, logical commits for easier review and potential reversion. |
| 59 | + - Demo functionality to reviewers when needed. |
| 60 | + |
| 61 | +## Security Practices |
| 62 | + |
| 63 | +- Sanitize all user inputs to prevent XSS. |
| 64 | +- Use Apollo Client’s error handling for GraphQL responses in `src/api`. |
| 65 | +- Implement role-based access control (RBAC) via GraphQL context. |
| 66 | +- Configure secure cookies (`HttpOnly`, `Secure`, `SameSite=Strict`) in `src/server`. |
| 67 | +- Enforce Content Security Policy (CSP) in Razzle’s server configuration in `src/server`. |
| 68 | +- Validate data from external sources (APIs, databases) for expected formats. |
| 69 | +- Check new dependencies with Snyk for vulnerabilities before adding via Yarn. |
| 70 | + |
| 71 | +## Form Development |
| 72 | + |
| 73 | +- Use custom form components built with Final Form and react-final-form in `src/components/form`: |
| 74 | + - Use components like `Form`, `Field`, and custom inputs for consistent behavior. |
| 75 | + - Define TypeScript interfaces in `src/common` for form data and props. |
| 76 | + - Use `react-final-form` hooks (e.g., `useForm`, `useField`) for form state management. |
| 77 | +- Integrate MUI v5 components (`TextField`, `Select`, etc.) within form components: |
| 78 | + - Apply `sx` prop, referencing `src/theme` for consistency. |
| 79 | +- Use `yup` for validation: |
| 80 | + - Store schemas in `src/common/validation`. |
| 81 | + - Ensure TypeScript compatibility. |
| 82 | + - Integrate with react-final-form for user-friendly error messages. |
| 83 | + |
| 84 | +## General Guidelines |
| 85 | + |
| 86 | +- Write clear, concise code with single-responsibility modules. |
| 87 | +- Add JSDoc comments for public functions and components (optional: include purpose and description). |
| 88 | +- Optimize performance: |
| 89 | + - Use `React.memo`, `useCallback`, `useMemo` for React components. |
| 90 | + - Minimize loop iterations, redundant operations, and memory allocations. |
| 91 | + - Process data in chunks for large datasets. |
| 92 | + - Optimize GraphQL queries in `src/api` for efficient data retrieval. |
| 93 | +- Avoid changing code outside the task scope; create separate PRs for refactors. |
| 94 | +- Keep responses friendly, informal, and under 1000 characters. |
| 95 | +- Reference `styleguide.md` in `docs/` for additional styling rules. |
| 96 | + |
| 97 | +## Testing |
| 98 | + |
| 99 | +- Use Jest and React Testing Library for unit tests: |
| 100 | + - Place tests in `__tests__` folders in `src/components` and `src/scenes`. |
| 101 | + - Mock GraphQL queries with `@apollo/client/testing` for `src/api` files. |
| 102 | + - Mock react-final-form for form tests using `react-final-form` testing utilities. |
| 103 | +- Write descriptive tests focusing on user interactions. |
| 104 | +- Ensure functional quality: |
| 105 | + - Unit testing in development. |
| 106 | + - Regression and smoke testing in production or development as needed. |
| 107 | +- Validate all acceptance criteria in PR reviews. |
| 108 | + |
| 109 | +## Additional Notes |
| 110 | + |
| 111 | +- Reference GraphQL schemas in `src/api/schema.graphql`. |
| 112 | +- Avoid external resource references unless specified. |
| 113 | +- If instructions seem ignored, remind Copilot to check this file.- Use tagged comments (`// cp tag`) to mark code for reference: |
| 114 | + - `example`: Best practice or model code. |
| 115 | + - `edge-case`: Necessary deviation from standards. |
| 116 | + - `best-practice`: Adherence to coding standards. |
| 117 | + - `anti-pattern`: Code to avoid (pending refactor). |
| 118 | + - `todo`: Needs improvement or refactoring. |
| 119 | + - `workaround`: Temporary fix for a limitation. |
| 120 | + - `performance`: Optimized code. |
| 121 | + - `security`: Security-critical code. |
| 122 | + - `test`: Exemplary test case. |
| 123 | + - `design-alignment`: Matches or deviates from design specs. |
| 124 | +- After the tag, optionally add notes to explain the context (e.g., `// cp example Reusable form with theme-based styling`). |
| 125 | +- Search for tags with `git grep "cp "` to collect examples for this document. |
0 commit comments