|
| 1 | +# Copilot Instructions |
| 2 | + |
| 3 | +This project features an **ASP.NET Core** backend (REST API) and a **Svelte 5 TypeScript** frontend (SPA). |
| 4 | +All contributions must respect existing formatting and conventions specified in the `.editorconfig` file. |
| 5 | +You are a distinguished engineer and are expected to deliver high-quality code that adheres to the guidelines below. |
| 6 | + |
| 7 | +--- |
| 8 | + |
| 9 | +## 1. General Coding Guidelines |
| 10 | + |
| 11 | +- **Code Style & Minimal Diffs:** |
| 12 | + - Match the file's existing style; use `.editorconfig` when unsure. |
| 13 | + - Preserve extra spaces, comments, and minimize diffs. |
| 14 | + - Always ask before creating new files, directories, or changing existing structures. |
| 15 | + - Always look at existing usages before refactoring or changing code to prevent new code from breaking existing code. |
| 16 | + - Assume any existing uncommitted code is correct and ask before changing it. |
| 17 | + - Don't add code comments unless necessary. Code should be self-explanatory. |
| 18 | + - Don't use deprecated or insecure libraries, algorithms or features. |
| 19 | + |
| 20 | +- **Modern Code Practices:** |
| 21 | + - Write complete, runnable code—no placeholders or TODOs. |
| 22 | + - Use modern language features, clear naming conventions, and defensive coding when necessary. |
| 23 | + - Follow SOLID, DRY, and clean code principles. Remove unused code. |
| 24 | + |
| 25 | +- **Behavior Management:** |
| 26 | + - Flag any user-visible changes for review. |
| 27 | + - Deliver exactly what’s requested—avoid adding unnecessary features unless explicitly instructed. |
| 28 | + |
| 29 | +--- |
| 30 | + |
| 31 | +## 2. Frontend Guidelines (Svelte 5 / TypeScript SPA) |
| 32 | + |
| 33 | +Located in the `src/Exceptionless.Web/ClientApp` directory. |
| 34 | + |
| 35 | +- **Framework & Best Practices:** |
| 36 | + - Use Svelte 5 in SPA mode with TypeScript and Tailwind CSS. |
| 37 | + - Follow modern ES6 best practices and the ESLint recommended configuration ([standardjs](https://standardjs.com)). |
| 38 | + - Code can be formatted and linted with `npm run format` and checked for errors with `npm run check` tasks. |
| 39 | + - Don't use namespace imports unless importing svelte-shadcn component or from a barrel export index file. |
| 40 | + - Limit use of $effect as there is usually a better way to solve the problem like using $derived. |
| 41 | + - All single-line control statements in JavaScript must be enclosed in curly braces to ensure unambiguous control flow, enhance readability, and prevent potential errors arising from unintended statement grouping. |
| 42 | + |
| 43 | +- **Architecture & Components:** |
| 44 | + - Follow the Composite Component Pattern. |
| 45 | + - Organize code into vertical slices (e.g., features aligned with API controllers) and maintain shared components in a central folder. |
| 46 | + - Use **kebab-case** for filenames and directories (e.g., `components/event-overview.svelte`). |
| 47 | + - Reexport generated code `src/Exceptionless.Web/ClientApp/src/lib/generated` from the respective feature models folder. |
| 48 | + - Always look for models in generated code before creating new models. |
| 49 | + - If a function returns a promise always await it. |
| 50 | + - **Do NOT** use any server-side Svelte features. |
| 51 | + |
| 52 | +- **UI, Accessibility & Testing:** |
| 53 | + - Ensure excellent keyboard navigation for all interactions. |
| 54 | + - Build forms with shadcn-svelte forms & superforms, and validate with class-validator. |
| 55 | + - Good examples are the manage account and login pages. |
| 56 | + - Use formatters `src/Exceptionless.Web/ClientApp/src/lib/features/shared/components/formatters` for displaying built-in types (date, number, boolean, etc.). |
| 57 | + - All dialogs should use shadcn-svelte dialog components. |
| 58 | + - Good examples are the mark fixed and delete stack dialogs. |
| 59 | + - Ensure semantic HTML, mobile-first design, and WCAG 2.2 Level AA compliance. |
| 60 | + - Use shadcn-svelte components (based on [bits-ui](https://bits-ui.com/docs/llms.txt)). |
| 61 | + - Look for new components in the shadcn-svelte documentation |
| 62 | + |
| 63 | +- **API Calls:** |
| 64 | + - Use TanStack Query for all API calls centralized in an `api.svelte.ts` file. |
| 65 | + - Leverage `@exceptionless/fetchclient` for network operations. |
| 66 | + |
| 67 | +- **Testing Tools:** |
| 68 | + - Unit Testing: Vitest |
| 69 | + - Component Testing: Testing Library |
| 70 | + - E2E Testing: Playwright |
| 71 | + |
| 72 | +- **Reference documentation:** |
| 73 | + - Always use Svelte 5 features: [https://svelte.dev/llms-full.txt](https://svelte.dev/llms-full.txt) |
| 74 | + - on:click -> onclick |
| 75 | + - import { page } from '$app/stores'; -> import { page } from '$app/state'; |
| 76 | + |
| 77 | +--- |
| 78 | + |
| 79 | +## 3. Backend Guidelines (ASP.NET Core / C#) |
| 80 | + |
| 81 | +- **Framework & Best Practices:** |
| 82 | + - Use the latest ASP.NET Core with C# and enable Nullable Reference Types. |
| 83 | + - Code can be formatted with `dotnet format` and checked for errors with `dotnet build`. |
| 84 | + |
| 85 | +- **Conventions & Best Practices:** |
| 86 | +- Adhere to the `.editorconfig` file and Microsoft's [coding conventions](https://learn.microsoft.com/en-us/dotnet/csharp/fundamentals/coding-style/coding-conventions). |
| 87 | +- Follow Microsoft's [unit testing best practices](https://learn.microsoft.com/en-us/dotnet/core/testing/unit-testing-best-practices). |
| 88 | + |
| 89 | +- **Architectural Considerations:** |
| 90 | + - Design services with awareness of distributed computing challenges. |
| 91 | + |
| 92 | +--- |
| 93 | + |
| 94 | +## 4. Security Guidelines |
| 95 | + |
| 96 | +- **Best Practices:** |
| 97 | + - Sanitize all user inputs and rigorously validate data. |
| 98 | + - Follow OWASP guidelines and implement a robust Content Security Policy. |
| 99 | + - Adopt Shift-Left security practices to identify vulnerabilities early. |
| 100 | + |
| 101 | +--- |
| 102 | + |
| 103 | +## 5. Developer Planning & Reflection |
| 104 | + |
| 105 | +- **Pre-Coding Reflection:** |
| 106 | + 1. Identify the problem or feature you’re solving. |
| 107 | + 2. Consider three possible approaches. |
| 108 | + 3. Choose the simplest approach that satisfies all requirements. |
| 109 | + 4. Clarify: |
| 110 | + - Can the solution be modularized into smaller functions? |
| 111 | + - Are there unnecessary abstractions? |
| 112 | + - Will the implementation be clear to a junior developer? |
| 113 | + |
| 114 | +- **Post-Coding Reflection:** |
| 115 | + 1. Review for refactor opportunities—can clarity or maintainability be improved? |
| 116 | + 2. Identify potential edge cases or areas prone to bugs. |
| 117 | + 3. Verify robust error handling and validation mechanisms. |
| 118 | + |
| 119 | +--- |
| 120 | + |
| 121 | +## 6. Code Reviews |
| 122 | + |
| 123 | +- **Focus Areas:** |
| 124 | + - Ensure adherence to complexity, consistency, and clean code standards. |
| 125 | + - Validate robust error handling and defensive coding practices. |
| 126 | + - Check for duplication and maintainable solutions. |
| 127 | + |
| 128 | +--- |
| 129 | + |
| 130 | +## 7. Debugging Guidelines |
| 131 | + |
| 132 | +1. **Reproduce** the issue with minimal steps and code. |
| 133 | +2. **Understand** the underlying problem thoroughly. |
| 134 | +3. **Form Hypotheses** about the cause. |
| 135 | +4. **Test & Verify** potential solutions. |
| 136 | +5. **Document** fixes and adjustments clearly for future reference. |
| 137 | + |
| 138 | +--- |
| 139 | + |
| 140 | +## 8. Project Structure |
| 141 | + |
| 142 | +```plaintext |
| 143 | +project-root/ |
| 144 | +├── build # Build files |
| 145 | +├── docker # Docker files |
| 146 | +├── k8s # Kubernetes files |
| 147 | +├── samples |
| 148 | +├── src |
| 149 | +│ ├── Exceptionless.AppHost # Aspire |
| 150 | +│ ├── Exceptionless.Core # Domain |
| 151 | +│ ├── Exceptionless.EmailTemplates # Email Templates |
| 152 | +│ ├── Exceptionless.Insulation # Concrete Implementations |
| 153 | +│ ├── Exceptionless.Job # ASP.NET Core Jobs |
| 154 | +│ ├── Exceptionless.Web # ASP.NET Core Web Application |
| 155 | +│ │ ├── ClientApp # Frontend SvelteKit Spa Application |
| 156 | +│ │ │ ├── api-templates # API templates for generated code using OpenApi |
| 157 | +│ │ │ ├── e2e |
| 158 | +│ │ │ ├── src # JavaScript SvelteKit application |
| 159 | +│ │ │ │ ├── lib |
| 160 | +│ │ │ │ │ ├── assets # Static assets |
| 161 | +│ │ │ │ │ ├── features # Vertical Sliced Features, each folder corresponds to an api controller |
| 162 | +│ │ │ │ │ │ ├── events # Event features (related to Events Controller) |
| 163 | +│ │ │ │ │ │ │ ├── components |
| 164 | +│ │ │ │ │ │ │ └── models |
| 165 | +│ │ │ │ │ │ ├── organizations |
| 166 | +│ │ │ │ │ │ ├── projects |
| 167 | +│ │ │ │ │ │ │ └── components |
| 168 | +│ │ │ │ │ │ ├── shared # Shared components used by all other features |
| 169 | +│ │ │ │ │ │ │ ├── api |
| 170 | +│ │ │ │ │ │ │ ├── components |
| 171 | +│ │ │ │ │ │ │ └── models |
| 172 | +│ │ │ │ │ │ ├── stacks |
| 173 | +│ │ │ │ │ │ │ └── components |
| 174 | +│ │ │ │ │ ├── generated # Generated code |
| 175 | +│ │ │ │ │ ├── hooks # Client hooks |
| 176 | +│ │ │ │ │ └── utils # Utility functions |
| 177 | +│ │ │ │ └── routes # Application routes |
| 178 | +│ │ │ │ ├── (app) |
| 179 | +│ │ │ │ │ ├── account |
| 180 | +│ │ │ │ │ └── stream |
| 181 | +│ │ │ │ ├── (auth) |
| 182 | +│ │ │ │ │ ├── login |
| 183 | +│ │ │ │ │ └── logout |
| 184 | +│ │ │ │ └── status |
| 185 | +│ │ │ └── static # Static assets |
| 186 | +│ │ ├── ClientApp.angular # Legacy Angular Client Application (Ignore) |
| 187 | +│ │ ├── Controllers # ASP.NET Core Web API Controllers |
| 188 | +│ └── tests # ASP.NET Core Unit and Integration Tests |
| 189 | +``` |
| 190 | + |
| 191 | +--- |
| 192 | + |
| 193 | +### Additional Considerations |
| 194 | + |
| 195 | +- **Expanding the Guidelines:** |
| 196 | + As the project evolves, consider including sample code snippets, decision flowcharts, or ASCII diagrams to clarify more complex guidelines. |
| 197 | + |
| 198 | +- **Continuous Improvement:** |
| 199 | + Regularly review and update these guidelines to stay aligned with evolving best practices and emerging technologies. |
| 200 | + |
| 201 | +- **Thoughtful Contribution:** |
| 202 | + Always strive to deliver code that not only functions well but also advances the overall maintainability and quality of the project. |
| 203 | + |
| 204 | +Let's keep pushing for clarity, usability, and excellence—both in code and user experience. |
0 commit comments