Ordnerstruktur für ein Node.js-Projekt

Ich stelle fest, dass Node.js Projekte häufig Ordner wie diese enthalten:

/ libs, / vendor, / support, / spec, / tests

Was genau bedeuten diese? Was ist der Unterschied zwischen ihnen und wo sollte ich referenzierten Code einfügen?

In Bezug auf die Ordner, die Sie erwähnt haben:

• /libs wird normalerweise für benutzerdefinierte verwendet classes/functions/modules
• /vendoroder /supportenthält Bibliotheken von Drittanbietern (als Git-Submodul hinzugefügt, wenn Git als Quellcodeverwaltung verwendet wird)
• /spec enthält Spezifikationen für BDD-Tests.
• /testsenthält die Unit-Tests für eine Anwendung (unter Verwendung eines Test-Frameworks, siehe hier )

HINWEIS: Beide /vendorund /supportsind veraltet, da NPM eine saubere Paketverwaltung eingeführt hat. Es wird empfohlen, alle Abhängigkeiten von Drittanbietern mit NPM und einer package.json-Datei zu behandeln

Beim Erstellen einer ziemlich großen Anwendung empfehle ich die folgenden zusätzlichen Ordner (insbesondere, wenn Sie eine Art MVC- / ORM-Framework wie Express oder Mungo verwenden ):

• /modelsenthält alle Ihre ORM-Modelle ( Schemasim Mungo genannt)
• /views enthält Ihre Ansichtsvorlagen (unter Verwendung einer beliebigen in Express unterstützten Vorlagensprache)
• /public enthält alle statischen Inhalte (Bilder, Stylesheets, clientseitiges JavaScript)
  • /assets/images enthält Bilddateien
  • /assets/pdf enthält statische pdf-Dateien
  • /css enthält Stylesheets (oder kompilierte Ausgabe von einer CSS-Engine)
  • /js enthält clientseitiges JavaScript
• /controllersEnthalten alle Ihre Express-Routen, getrennt nach Modul / Bereich Ihrer Anwendung (Hinweis: Wenn Sie die Bootstrapping-Funktion von Express verwenden, wird dieser Ordner aufgerufen. /routes)

Ich habe mich daran gewöhnt, meine Projekte so zu organisieren, und ich denke, es funktioniert ziemlich gut.

Update für CoffeeScript-basierte Express-Anwendungen (mithilfe von Connect-Assets ):

• /app enthält Ihr kompiliertes JavaScript
• /assets/ enthält alle clientseitigen Assets, die kompiliert werden müssen
  • /assets/js enthält Ihre clientseitigen CoffeeScript-Dateien
  • /assets/css enthält alle Ihre LESS / Stylus-Stylesheets
• /public/(js|css|img) enthält Ihre statischen Dateien, die von keinem Compiler verarbeitet werden
• /src enthält alle Ihre serverseitigen spezifischen CoffeeScript-Dateien
• /test enthält alle Unit-Test-Skripte (implementiert mit einem Test-Framework Ihrer Wahl)
• /views enthält alle Ihre Express-Ansichten (sei es Jade, EJS oder eine andere Template-Engine)

Es gibt eine Diskussion über GitHub aufgrund einer ähnlichen Frage: https://gist.github.com/1398757

Sie können andere Projekte als Anleitung verwenden und in GitHub suchen nach:

• ThreeNodes.js - scheint meiner Meinung nach eine spezifische Struktur zu haben, die nicht für jedes Projekt geeignet ist;
• leichter - eine einfachere Struktur, aber ohne Organisation;

Und schließlich schlägt in einem Buch ( http://shop.oreilly.com/product/0636920025344.do ) diese Struktur vor:

├── index.html
├── js/
│   ├── main.js
│   ├── models/
│   ├── views/
│   ├── collections/
│   ├── templates/
│   └── libs/
│       ├── backbone/
│       ├── underscore/
│       └── ...
├── css/
└── ...

Weitere Beispiele aus meiner Projektarchitektur finden Sie hier:

├── Dockerfile
├── README.md
├── config
│   └── production.json
├── package.json
├── schema
│   ├── create-db.sh
│   ├── db.sql
├── scripts
│   └── deploy-production.sh 
├── src
│   ├── app -> Containes API routes
│   ├── db -> DB Models (ORM)
│   └── server.js -> the Server initlializer.
└── test

Grundsätzlich ist die logische App in DB- und APP-Ordner innerhalb des SRC-Verzeichnisses getrennt.

Dies ist eine indirekte Antwort auf die Ordnerstruktur selbst, die sehr verwandt ist.

Vor ein paar Jahren hatte ich die gleiche Frage, nahm eine Ordnerstruktur, musste aber später viel Verzeichnis verschieben, weil der Ordner für einen anderen Zweck gedacht war als den, den ich im Internet gelesen habe, dh was ein bestimmter Ordner hat unterschiedliche Bedeutungen für unterschiedliche Personen in einigen Ordnern.

Nachdem ich nun mehrere Projekte durchgeführt habe, zusätzlich zu den Erläuterungen in allen anderen Antworten, zur Ordnerstruktur selbst, würde ich dringend empfehlen, der Struktur von Node.js selbst zu folgen, die unter folgender Adresse zu sehen ist: https://github.com/ nodejs / node . Es enthält sehr detaillierte Informationen zu allen, beispielsweise Lintern und anderen, welche Datei- und Ordnerstruktur sie haben und wo. Einige Ordner haben eine README-Datei, die erklärt, was sich in diesem Ordner befindet.

Es ist gut, mit der obigen Struktur zu beginnen, da eines Tages eine neue Anforderung eintritt und Sie einen Verbesserungsbedarf haben, da bereits Node.js selbst folgt, das über viele Jahre hinweg beibehalten wird.

Hoffe das hilft.

Es ist wichtig anzumerken, dass es keinen Konsens darüber gibt, was der beste Ansatz ist, und dass verwandte Rahmenbedingungen im Allgemeinen bestimmte Strukturen nicht durchsetzen oder belohnen.

Ich finde das frustrierend und riesig, aber genauso wichtig. Es ist eine Art heruntergespielte Version (aber IMO wichtiger) des Styleguide-Problems . Ich möchte darauf hinweisen, weil die Antwort dieselbe ist: Es spielt keine Rolle, welche Struktur Sie verwenden, solange sie gut definiert und kohärent ist .

Daher würde ich vorschlagen, nach einem umfassenden Leitfaden zu suchen, der Ihnen gefällt, und deutlich zu machen, dass das Projekt darauf basiert.

Es ist nicht einfach, besonders wenn Sie neu in diesem Bereich sind! Erwarten Sie Stunden mit Nachforschungen. Die meisten Anleitungen empfehlen eine MVC-ähnliche Struktur. Während dies vor einigen Jahren eine gute Wahl gewesen sein könnte, ist dies heutzutage nicht unbedingt der Fall. Zum Beispiel ist hier ein anderer Ansatz .

Angenommen, wir sprechen über Webanwendungen und das Erstellen von APIs:

Ein Ansatz besteht darin, Dateien nach Funktionen zu kategorisieren , ähnlich wie eine Mikrodienstarchitektur aussehen würde. Der größte Gewinn meiner Meinung nach ist, dass es sehr einfach ist zu erkennen, welche Dateien sich auf eine Funktion der Anwendung beziehen.

Der beste Weg, dies zu veranschaulichen, ist ein Beispiel:

Wir entwickeln eine Bibliotheksanwendung. In der ersten Version der Anwendung kann ein Benutzer:

• Suchen Sie nach Büchern und sehen Sie Metadaten von Büchern
• Suchen Sie nach Autoren und sehen Sie sich ihre Bücher an

In einer zweiten Version können Benutzer auch:

• Erstellen Sie ein Konto und melden Sie sich an
• Bücher ausleihen / ausleihen

In einer dritten Version können Benutzer auch:

• Speichern Sie eine Liste der Bücher, die sie lesen / Favoriten markieren möchten

Zuerst haben wir folgende Struktur:

books
  ├─ controllers
  │   ├─ booksController.js
  │   └─ authorsController.js
  │
  └─ entities
      ├─ book.js
      └─ author.js

Wir fügen dann die Benutzer- und Leihfunktionen hinzu:

user
  ├─ controllers
  │   └─ userController.js
  ├─ entities
  │   └─ user.js
  └─ middleware
       └─ authentication.js
loan
  ├─ controllers
  │   └─ loanController.js
  └─ entities
      └─ loan.js

Und dann die Favoritenfunktionalität:

favorites
  ├─ controllers
  │   └─ favoritesController.js
  └─ entities
      └─ favorite.js

Für jeden neuen Entwickler, dem die Aufgabe übertragen wird, hinzuzufügen, dass die Buchsuche auch Informationen zurückgeben sollte, wenn ein Buch als Favorit markiert wurde, ist es wirklich leicht zu erkennen, wo im Code er / sie suchen sollte.

Wenn dann der Produktbesitzer vorbeikommt und ausruft, dass die Favoritenfunktion vollständig entfernt werden soll, ist es einfach, sie zu entfernen.