|
| 1 | + |
| 2 | +# GitHub Copilot Instructions for This Repository |
| 3 | + |
| 4 | +Welcome to the Nais Examples repository! This document provides guidance for using GitHub Copilot effectively in this codebase. Please follow the instructions below to ensure consistency, quality, and best practices across all services and technologies in this repository. |
| 5 | + |
| 6 | +--- |
| 7 | + |
| 8 | +## General Instructions |
| 9 | + |
| 10 | +- **Code Quality:** Always generate clean, readable, and idiomatic code. Follow the conventions of the language and framework in use. |
| 11 | +- **Documentation:** Add or update comments and documentation for new code, especially for public APIs and complex logic. |
| 12 | +- **Testing:** When adding new features or fixing bugs, generate or update relevant tests. |
| 13 | +- **Security:** Avoid hardcoding secrets or credentials. Use environment variables or secret management solutions. |
| 14 | +- **Error Handling:** Implement proper error handling and logging. Avoid silent failures. |
| 15 | +- **Consistency:** Follow the existing project structure and naming conventions. |
| 16 | +- **Dependencies:** Use only necessary dependencies. Prefer official or well-maintained libraries. |
| 17 | +- **Pull Requests:** Ensure all code passes linting, formatting, and tests before submitting a PR. |
| 18 | + |
| 19 | +--- |
| 20 | + |
| 21 | + |
| 22 | +## Language & Framework Specific Instructions |
| 23 | + |
| 24 | +### 1. Next.js (Frontend) |
| 25 | +- Use functional React components and hooks. |
| 26 | +- Prefer TypeScript for new files/components. |
| 27 | +- Use Tailwind CSS for UI. |
| 28 | +- Organize components in the `components/` directory and pages in the `pages/` or `app/` directory. |
| 29 | +- Use Next.js API routes for backend logic only when necessary. |
| 30 | +- Optimize for accessibility and performance. |
| 31 | +- Use environment variables for configuration (never commit secrets). |
| 32 | + |
| 33 | +### 2. Kotlin + Ktor (Backend) |
| 34 | +- Use idiomatic Kotlin (prefer `val` over `var`, use data classes, etc.). |
| 35 | +- Organize code by feature (routes, services, repositories, models, etc.). |
| 36 | +- Use Ktor features for routing, dependency injection, and configuration. |
| 37 | +- Use JPA/Hibernate or Exposed for database access; prefer constructor injection. |
| 38 | +- Write integration and unit tests for routes and services. |
| 39 | +- Use configuration files (`application.conf` or `application.yaml`) for environment-specific settings. |
| 40 | + |
| 41 | +### 3. Go (Load Generator) |
| 42 | +- Use idiomatic Go (short variable names, error handling, etc.). |
| 43 | +- Organize code by package (cmd, internal, etc.). |
| 44 | +- Write clear, minimal code for load generation and HTTP requests. |
| 45 | +- Add comments and documentation for exported functions. |
| 46 | +- Write unit tests for core logic if applicable. |
| 47 | + |
| 48 | +### 4. PostgreSQL (Database) |
| 49 | +- Use migrations (e.g., Flyway, Liquibase, or manual SQL) for schema changes if needed. |
| 50 | +- Store connection details in environment variables or secrets. |
| 51 | +- Do not commit database dumps or sensitive data. |
| 52 | + |
| 53 | +### 5. Docker & Docker Compose |
| 54 | +- Write clear, minimal Dockerfiles for each service. |
| 55 | +- Use multi-stage builds for production images when possible. |
| 56 | +- Keep `docker-compose.yaml` up to date with all services and dependencies. |
| 57 | +- Expose only necessary ports and use environment variables for configuration. |
| 58 | + |
| 59 | +--- |
| 60 | + |
| 61 | +## Additional Notes |
| 62 | +- For more details on each service, see the README in the respective subdirectory. |
| 63 | +- If you are unsure about conventions or best practices, refer to the official documentation for the language or framework in use. |
| 64 | +- When in doubt, prefer clarity and maintainability over cleverness. |
0 commit comments