Das fängt ja schon mal schlecht an ^^
Aber ich finde nicht, dass das schlampig ist, persönlich 
Ok, ich fix das 
Ich werde dieses Paket verwenden, um das plattformübergreifend zu machen:
Ich habe das Ding einfach repariert, indem ich ‹ SET › vor den NODE_ENV gesetzt habe ^^
Aber ich weiß nicht, ob es danach auf den anderen Plattformen funktionieren wird
Edit: Ein Start-Skript hinzufügen und auch npm i im Root-Paket wäre praktisch
Nein, genau dafür gibt es ein Modul, das verschiedene Plattformen verwaltet 
Ich habe gepusht, das sollte es bei dir beheben!
Übrigens, wenn es sich um devDependencies handelt, ist es nicht so schlimm, kleine Abhängigkeiten für so etwas zu installieren, man muss nur sicherstellen, dass diese Abhängigkeiten nicht im Produktionsbuild enthalten sind, sonst wird es schnell schwerfällig.
Ja, das ist auf einmal viel besser ^^
Ich weiß nicht, ich überlege, ob ich den Ordner « controllers » und « middlewares » in einen Ordner « api » legen soll. Aber zu viele Unterordner sind nicht immer die beste Idee…
Ja! Später würde ich das Root-Paket konfigurieren, wenn das Frontend da ist.
Alles muss für den Entwickler und den Benutzer transparent sein.
In der Entwicklung würde es den Hot-Reload-Server für Frontend und Backend starten
In der Produktion würde es einfach den Server starten, der die gebaute SPA ausliefert
Ja, tatsächlich ist das nicht unbedingt die beste Idee, so verliert man schnell den Überblick in den Bergen von Unterordnern ^^
Kleine Frage, hast du den ESLint-Test erfolgreich bestanden, nehme ich an?
Ja, warum funktioniert es bei dir nicht?
Es funktioniert doch lokal und auf Travis!
Übrigens, deine Meinung zum Repo könnte interessant sein! Findest du es sauber?
Nein, ich bekomme einen Fehler 416 ins Gesicht!
Aber ich vermute, dass VSCode die falsche ESLint-Konfiguration nicht verwendet… obwohl es mir scheint, dass es automatisch die Projektkonfiguration verwendet
Ich muss etwas übersehen haben… das ist das erste Mal, dass es mir das macht..
Ah, das ist sicherlich das Problem! Untersuchung deiner VSCode-Konfiguration..
Ach, ist schon gut, ich habe es gefunden, danke Windows
Es geht um Zeilenumbrüche, Windows verwendet standardmäßig CRLF, während Mac und Linux nur LF verwenden. Da alle Dateien auf dem Mac erstellt wurden, interpretiert mein VsCode die ESLint-Regeln falsch und zeigt mir überall Zeilenumbruchfehler an 
Hallo zusammen!
Ich habe gerade eine erste Version des Datenbankmodells fertiggestellt
Sagt mir, was ihr davon haltet, vielleicht gibt es Dinge, die geändert werden müssen oder Dinge, die vergessen wurden. Sagt mir Bescheid!
Ich habe dir auf deine PR geantwortet, wir wollen nicht, dass die Regel deaktiviert wird! Sonst wird es ein Chaos. Du musst deinen IDE so konfigurieren, dass er LF ohne Probleme verarbeitet (das ist in den Einstellungen von VSCode)
Weitere Neuerungen: Ich habe die Struktur der package.json-Dateien der internen Dienste in Gladys 4 definiert.
Hier ein Beispiel:
{
"name": "gladys-example",
"main": "index.js",
"os": [
"darwin",
"linux",
"win32"
],
"cpu": [
"x64",
"arm",
"arm64"
],
"scripts": {},
"dependencies": {
"axios": "^0.18.0"
}
}
Der Modul muss nun zwei zusätzliche Attribute angeben: « os » und « cpu », um die Plattformen anzugeben, auf denen der Dienst läuft.
Wenn man einen Build von Gladys für eine Plattform erstellt, wird NPM die notwendigen Überprüfungen durchführen, ob der Dienst installiert werden kann oder nicht.
- Falls ja, wird der Dienst installiert
- Falls nein, wird der Dienst nicht installiert und mit einem speziellen Fehlercode (Typ « platform_not_compatible ») deaktiviert, und daher nicht beim Start von Gladys geladen
Diese Regeln:
- Eine gültige package.json haben
- Ein « os »- und « cpu »-Attribut in der package.json haben
Werden durch eine Reihe von Tests überprüft, damit sichergestellt ist, dass alle Module diesen Anforderungen entsprechen.
@MathieuA Also, ich habe die Architektur und die Art, wie die Gladys-Bibliothek und die Abhängigkeiten instanziiert werden, ein wenig geändert.
Die Controller sehen jetzt so aus:
Ich finde das klarer, und alle Controller einer Entität in einer einzigen Datei zu haben, sehe ich kein Problem, die Controller sind so dünn… Und ich bevorzuge Abhängigkeitsinjektion statt require hier.
Dann, eine weitere Änderung, die Gladys-Bibliothek muss ebenfalls instanziiert werden, damit wir die « states » einfacher verwalten können.
Ich erkläre: Früher hatte ich die Angewohnheit, « shared.js »-Dateien zu erstellen, um Zustände zu speichern, die zwischen mehreren Dateien geteilt werden. Das hat funktioniert, aber es ist nicht ideal, im Grunde habe ich require() als Singleton-Anbieter verwendet ^^
Vorschlag: Genau wie die Module ist jeder Service eine Funktion, die Funktionen zurückgibt (im Grunde ist es wie eine Klasse, die instanziiert werden muss)
Also, um Gladys zu starten, machen wir:
https://github.com/GladysAssistant/gladys-4-playground/blob/master/server/index.js
Ich denke, wir werden einen klareren App-Lifecycle und ein saubereres Zustandmanagement haben.
PS: Ich habe « controllers » und « middleware » und « routes.js » in einen Ordner « api » verschoben, ich finde das klarer
Wenn jemand Feedback hat, bin ich offen dafür 
Ahah, ich wusste, dass du mir das antworten würdest! ^^
Aber es wird ein Chaos, wenn du diese Regel nicht deaktivierst
Denn ich habe nachgeschaut und man kann VSCode nicht so konfigurieren, dass es automatisch den Zeilenumbruch-Typ berücksichtigt. Die einzige Konfiguration, die man vornehmen kann, ist, den Zeilenumbruch beim Erstellen einer neuen Datei festzulegen. Aber bei bestehenden Dateien ist das einzige Mittel, sie manuell zu ändern, aber das führt zu falschen Änderungen für Git, die ich dann commiten müsste… aber das ist ein bisschen blöd.
Umso mehr, weil ich nicht der Einzige bin, der auf Windows entwickelt, also wird es sicher Konflikte mit anderen geben. Und wenn sie oder ich dir PRs für neue Dateien mit Windows-Zeilenumbrüchen machen, wird das zu Fehlern bei den automatischen Tests führen oder sogar, wenn es bei dir ist!
Und ehrlich gesagt, mit den wenigen Dateien, die es im Projekt gibt, habe ich schon über 400 Fehler beim Testen bei mir, also wenn die Entwicklung weiter voranschreitet, werde ich die Idee aufgeben, den Test zu starten
Ich habe nachgeschaut, ob man etwas mit der ESLint-Konfiguration machen könnte, aber anscheinend ist nichts vorgesehen, es ist entweder das eine oder das andere 
Also dachte ich, das Beste wäre, diese Regel zu deaktivieren, ist ja nicht so, als würde ich die Kommentarprüfung deaktivieren 
Heyy keine Panik, wir finden eine Lösung ^^
Ist es normal, dass man im Projekt konsistent ist, oder? Alle ernsthaften Open-Source-Projekte machen das, wenn wir nach einem Tag mit einem strengen ESlint schon aufgeben, kommen wir nicht weit.
(Ich sage das, weil diese Regel eindeutig die einfachste Regel ist, danach gibt es noch strengere Regeln zum Codierstil)
Ich habe im Internet gesucht und es ist möglich, eine .editorconfig-Datei im Git-Repository zu erstellen, die deinem Vscode anzeigt, dass dieses Projekt „LF“ als Zeilenendstil gewählt hat. Es ist ein plattformübergreifendes Dateiformat, also hilft es auch Entwicklern unter Atom oder anderen IDEs.
Beispiel in einem Open-Source-Projekt:
Kannst du das testen? Wenn es das ist, würde ich diese Datei im Git ablegen
Wenn es nicht das ist, habe ich Dutzende von Themen zu diesem Thema gefunden, es ist ein grundlegendes Problem, wir finden eine Lösung
Ein anderes Problem könnte sein, dass dein Git so konfiguriert ist, dass es alle LF durch CRLF ersetzt, wenn du pullst.
Ich bin total einverstanden ^^
Aber nachdem ich gestern stundenlang gesucht habe, hat es mich genervt
Den hatte ich nicht! Und es funktioniert! Ich war auch auf eine Geschichte mit einer .gitattributes-Datei gestoßen, aber das hat nicht funktioniert. Es ist ein bisschen mystisch, weil VSCode mir unten den Windows-Zeilentyp anzeigt, aber ich habe keine Fehler mehr 
Ah, das habe ich auch versucht, aber es hat nichts gebracht
Aber in diesem Fall funktioniert die editorconfig-Datei perfekt!
Das ist normal!
Im Grunde genommen ist das passiert, dass, als du das Projekt geklont hast, entweder Vscode oder Git dachte, dass du das Projekt in CRLF umwandeln möchtest, und alle Dateien von LF zu CRLF konvertiert hat (das wollen wir nicht)
Also würde ich Folgendes tun:
1/ Wir müssen diese berühmte Datei zu Git hinzufügen
2/ Du klonst Git erneut, und wir schauen, ob es gut ist oder nicht
- Wenn es gut ist, war Vscode der Übeltäter
- Wenn es nicht gut ist, ist Git der Übeltäter, du hast einen Parameter, der besagt, dass das Projekt beim Pullen in CRLF konvertiert werden soll (mein zweiter Link)