Erste Schritte mit Devin

Erstellen Sie einen neuen Endpunkt /users/stats, der ein JSON-Objekt mit der Anzahl der Benutzer und dem durchschnittlichen Registrierungsalter zurückgibt.

Verwenden Sie unsere bestehende users-Tabelle in PostgreSQL.

Sie können den Endpunkt /orders/stats in statsController.js als Referenz dafür nutzen, wie wir Antworten strukturieren.

Stellen Sie sicher, dass der neue Endpunkt von der Test-Suite StatsController.test.js abgedeckt wird.

Fügen Sie Jest-Tests für die AuthService-Methoden login und logout hinzu.

Stellen Sie sicher, dass die Testabdeckung für diese beiden Funktionen mindestens 80 % beträgt.

Verwenden Sie UserService.test.js als Beispiel.

Führen Sie nach der Implementierung `npm test -- --coverage` aus und überprüfen Sie, ob der Coverage-Bericht für beide Funktionen > 80 % anzeigt.

Bestätigen Sie außerdem, dass die Tests sowohl mit gültigen als auch mit ungültigen Anmeldedaten erfolgreich sind und dass logout die Sitzungsdaten ordnungsgemäß löscht.

Migrieren oder Refaktorisieren vorhandenen Codes
Migrieren Sie logger.js von JavaScript zu TypeScript.

Wir haben bereits eine tsconfig.json und eine LoggerTest.test.js-Suite zur Validierung.

Stellen Sie sicher, dass der Code ohne Fehler kompiliert, und ändern Sie auf keinen Fall die bestehende Konfiguration!

Nach der Migration überprüfen Sie das Ergebnis, indem Sie:
1) `tsc` ausführen, um zu bestätigen, dass keine Typfehler auftreten
2) die Test-Suite mit `npm test LoggerTest.test.js` ausführen, um sicherzustellen, dass alle Tests bestehen
3) prüfen, dass alle bestehenden Logger-Methodenaufrufe in der gesamten Codebasis weiterhin ohne Typfehler funktionieren.

Wir wechseln von pg zu Sequelize (siehe https://sequelize.org/api/v6/identifiers).

Bitte aktualisiere die UserModel-Abfragen, sodass sie Sequelize-Methoden verwenden.

Sieh dir das OrderModel an, um zu sehen, wie wir das in dieser Codebasis machen.

Nach der Implementierung bitte wie folgt verifizieren:
1) Führe `npm run test:integration UserModel.test.js` aus, um sicherzustellen, dass alle Integrationstests bestehen
2) Stelle sicher, dass sich die Performance der Abfragen nicht verschlechtert hat, indem du die Ausführungszeit für einen Testdatensatz mit 1000 Benutzern prüfst
3) Überprüfe, dass alle CRUD-Operationen weiterhin die Datenintegrität gewährleisten, indem du `npm run test:e2e user-flows.test.js` ausführst

## Übersicht
Die Aufgabe besteht darin, einen schnellen Pull Request für ein Repository zu erstellen.
Da dies ein „schneller“ PR ist, musst du keinen Code ausführen oder etwas testen; erstelle einfach einen PR und der User übernimmt das Testing. Deine einzige Verantwortung ist das Lesen und Schreiben von Code.

## Was vom User benötigt wird
- Das Repository, zu dem ein Pull Request erstellt werden soll

## Vorgehen
### Richte deine Arbeitsumgebung ein
1. Navigiere auf deinem Rechner zum relevanten Repository (kläre das mit dem User, wenn du es nicht herausfinden kannst).
    - Checke den Main-Branch aus und notiere dir dessen Namen.
    - Wechsle auf einen neuen Branch, da du einen Pull Request erstellen wirst. Der Name des Branches muss dem Format `devin/<your-branch-name>/X` entsprechen, wobei X eine Zufallszahl ist. Zum Beispiel `devin/fix-popup/3234`. Führe `git remote -v && git pull && git checkout -b devin/{branch-name}/$RANDOM` aus und ersetze `{branch-name}` mit dem Namen des Branches, den du erstellen möchtest.
2. Studiere die Anfrage, die Codebasis und plane die Änderungen
    - Überprüfe die relevantesten Dateien und Codeabschnitte und identifiziere relevante Snippets.
    - Informiere den User über deinen Plan
### Arbeite am PR selbst
3. Nimm die Codeänderungen vor
    - Ändere nichts, was nicht ausdrücklich vom User angefordert wurde
4. Erstelle den PR
    - Committe und pushe die Änderungen und informiere den User.
    - Siehe den Abschnitt mit Hinweisen für den genauen Befehl zum Erstellen des PR.
    - Erstelle einen Pull Request und prüfe den PR, um sicherzustellen, dass alles in Ordnung aussieht.
    - Stelle sicher, dass alle GitHub Actions erfolgreich durchlaufen und nimm bei Bedarf Änderungen vor, bis sie es tun.
    - Sende den PR-Link an den User und fasse zusammen, was du geändert hast.
5. Gehe auf Feedback aus dem Review ein; sende den PR-Link jedes Mal erneut, wenn du Änderungen vornimmst
    - Wenn du Aktualisierungen vornehmen musst, pushe einfach weitere Commits auf denselben Branch; erstelle keinen neuen


## Aufgabenspezifikation
- Der PR-Link ist in deinen Nachrichten an den User enthalten
- Der PR wurde nach seiner Erstellung überprüft
- Der PR enthält keine unbeabsichtigten Änderungen
- Der PR ändert nichts, was nicht ausdrücklich vom User angefordert wurde
- Die PR-Beschreibung sollte eine Zusammenfassung der Änderungen enthalten, formatiert als Checkliste
- Die PR-Beschreibung sollte erwähnen, dass der Code ohne Tests geschrieben wurde, und den Punkt - [ ] Test the changes als Eintrag enthalten
- Die PR-Beschreibung sollte folgenden Footer enthalten: "Dieser PR wurde von [Devin](https://devin.ai/) :angel: geschrieben"
- Die PR-Beschreibung sollte alle Metadaten enthalten, die der User bereitgestellt hat (z. B. Linear-Ticket-Tags in der entsprechenden Syntax)
- Die PR-Beschreibung sollte nicht fehlerhaft formatiert sein (verwende --body-file statt --body, wenn Zeilenumbrüche beschädigt werden!)

## Verbotene Aktionen
- Versuche NICHT, über den Browser auf github.com zuzugreifen; du wirst dort nicht authentifiziert sein.
- NIEMALS Branches mit force push überschreiben! Bevorzuge Merging statt Rebase, damit du keine Arbeit verlierst.
- NICHT direkt auf den Main-Branch pushen.

## Hinweise und Tipps
- Überprüfe den Namen des Main-Branches (kann `main` oder `master` sein) mit `git branch` noch einmal.
- Für Repos mit CI/CD über GitHub Actions kannst du Build-Logs mit der `gh`-CLI einsehen. Wenn du gebeten wirst, einen Build zu reparieren oder Lint-Fehler zu beheben, solltest du mit den jüngsten Build-Logs beginnen.
- Überprüfe `git status`, bevor du Dateien committest oder hinzufügst.
- Verwende `git diff`, um dir vor dem Commit anzusehen, welche Änderungen du vorgenommen hast.
- Wenn du ein bestehendes Repo aktualisierst, verwende die `gh`-CLI, um Pull Requests zu erstellen.
- Sende den PR-Link jedes Mal an den User, wenn du ein Update machst, und bitte ihn um ein erneutes Review, damit es für ihn bequem ist.
- Du solltest bereits berechtigt sein, auf alle Repositories zuzugreifen, über die der User dich informiert. Falls nicht, bitte den User um Zugriff.