Structure de dossiers pour un projet Node.js

346

Je remarque que les projets Node.js incluent souvent des dossiers comme ceux-ci:

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

Qu'est-ce que cela signifie exactement? Quelle est la différence entre eux et où dois-je inclure le code référencé?

node.js

— guilin 桂林
source

439

Concernant les dossiers que vous avez mentionnés:

/libs est généralement utilisé pour la personnalisation classes/functions/modules
/vendorou /supportcontient des bibliothèques tierces (ajoutées comme sous-module git lors de l'utilisation de git comme contrôle de source)
/spec contient des spécifications pour les tests BDD.
/testscontient les tests unitaires d'une application (en utilisant un framework de test, voir ici )

REMARQUE: les deux /vendoret /supportsont obsolètes depuis que NPM a introduit une gestion de package propre. Il est recommandé de gérer toutes les dépendances tierces en utilisant NPM et un fichier package.json

Lors de la construction d'une application assez volumineuse, je recommande les dossiers supplémentaires suivants (surtout si vous utilisez une sorte de MVC- / ORM-Framework comme express ou mangouste ):

/modelscontient tous vos modèles ORM (appelés Schemasmangouste)
/views contient vos modèles d'affichage (en utilisant n'importe quel langage de modèles pris en charge dans express)
/public contient tout le contenu statique (images, feuilles de style, JavaScript côté client)
- /assets/images contient des fichiers image
- /assets/pdf contient des fichiers pdf statiques
- /css contient des feuilles de style (ou une sortie compilée par un moteur css)
- /js contient du JavaScript côté client
/controllerscontient tous vos itinéraires express, séparés par le module / la zone de votre application (remarque: lorsque vous utilisez la fonctionnalité d'amorçage express, ce dossier est appelé /routes)

Je me suis habitué à organiser mes projets de cette façon et je pense que ça marche plutôt bien.

Mise à jour pour les applications Express basées sur CoffeeScript (en utilisant les actifs de connexion ):

/app contient votre code JavaScript compilé
/assets/ contient tous les actifs côté client qui nécessitent une compilation
- /assets/js contient vos fichiers CoffeeScript côté client
- /assets/css contient toutes vos feuilles de style LESS / Stylus
/public/(js|css|img) contient vos fichiers statiques qui ne sont gérés par aucun compilateur
/src contient tous vos fichiers CoffeeScript spécifiques côté serveur
/test contient tous les scripts de tests unitaires (mis en œuvre en utilisant un framework de test de votre choix)
/views contient toutes vos vues express (que ce soit jade, ejs ou tout autre moteur de template)

— Schaermu
source

5

où mettriez-vous vos js, css, images côté client? suggéreriez-vous une structure de dossier similaire dans le dossier public, comme: public / assets public / assets / css public / assets / images public / assets / docs public / libs public / support public / tests public / models public / views public / controllers ?

— ezmilhouse

2

expressjs crée un répertoire ./routes, est-ce la même chose que ./controllers dans votre exemple?

— chovy

2

Pourquoi ne créez-vous pas un générateur Yeoman avec cette proposition? Cela pourrait devenir une norme.

— Jayr Motta

+1 Venant d'ASP.NET MVC, appeler le dossier "routes" "contrôleurs" a beaucoup plus de sens pour moi.

— adam0101

Question, les structures de répertoires ne sont-elles pas normalement générées par le framework (ie Symfony pour PHP)? Avec Express par exemple, aucune structure de répertoire n'est créée correctement? les développeurs doivent créer et maintenir manuellement la conception et les itinéraires MVC? J'apprécie tout commentaire, je suis nouveau sur Express

— AnchovyLegend

49

Il y a une discussion sur GitHub à cause d'une question similaire à celle-ci: https://gist.github.com/1398757

Vous pouvez utiliser d'autres projets pour vous guider, recherchez dans GitHub:

ThreeNodes.js - à mon avis, semble avoir une structure spécifique qui ne convient pas à chaque projet;
plus léger - une structure plus simple, mais manque un peu d'organisation;

Et enfin, dans un livre ( http://shop.oreilly.com/product/0636920025344.do ) suggère cette structure:

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

— Paulo Oliveira
source

J'ai créé un module pour exiger des fichiers de manière dynamique, vous permettant de structurer votre projet par fonctionnalité plutôt que par le modèle, la vue et le contrôleur typiques. J'espère que cela aide quelqu'un: github.com/ssmereka/crave

— Scott

13

Plus d'exemples de l'architecture de mon projet, vous pouvez voir ici:

├── 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

Fondamentalement, l'application logique est séparée des dossiers DB et APP dans le répertoire SRC.

— Daniel Chernenkov
source

si votre application contient également une application frontale, mettez-vous cela sous srcou l'application frontale obtient-elle son propre dossier (avec sa propre package.jsonstructure de dossiers et similaire)?

— wal

2

@wal Je préfère séparer les projets frontend dans un autre référentiel car il est plus organisé

— Daniel Chernenkov

2

C'est une réponse indirecte, sur la structure du dossier elle-même, très liée.

Il y a quelques années, j'avais la même question, j'ai pris une structure de dossiers, mais j'ai dû faire beaucoup de répertoires plus tard, car le dossier était destiné à un but différent de celui que j'ai lu sur Internet, c'est-à-dire ce qu'un dossier particulier a différentes significations pour différentes personnes sur certains dossiers.

Maintenant, après avoir fait plusieurs projets, en plus des explications dans toutes les autres réponses, sur la structure de dossiers elle-même, je suggère fortement de suivre la structure de Node.js elle-même, qui peut être vue sur: https://github.com/ nodejs / node . Il contient de nombreux détails sur tous, par exemple les linters et autres, sur la structure de fichiers et de dossiers dont ils disposent et où. Certains dossiers ont un fichier README qui explique ce qu'il y a dans ce dossier.

Commencer dans la structure ci-dessus est bien car un jour une nouvelle exigence arrive et mais vous aurez une marge d'amélioration car elle est déjà suivie par Node.js lui-même qui est maintenu depuis de nombreuses années maintenant.

J'espère que cela t'aides.

— Manohar Reddy Poreddy
source

1

Il est important de noter qu'il n'y a pas de consensus sur la meilleure approche et que les cadres associés en général n'appliquent pas et ne récompensent pas certaines structures.

Je trouve que c'est une surcharge énorme et frustrante mais tout aussi importante. Il s'agit en quelque sorte d'une version minimisée (mais plus importante de l'OMI) du problème du guide de style . J'aime le souligner parce que la réponse est la même: peu importe la structure que vous utilisez tant qu'elle est bien définie et cohérente .

Je proposerais donc de chercher un guide complet que vous aimez et de préciser que le projet est basé sur cela.

Ce n'est pas facile, surtout si vous êtes nouveau dans ce domaine! Attendez-vous à passer des heures à faire des recherches. Vous trouverez la plupart des guides recommandant une structure de type MVC. Il y a plusieurs années, cela aurait pu être un choix solide, mais ce n'est pas nécessairement le cas de nos jours. Par exemple, voici une autre approche .

— thisismydesign
source

1

En supposant que nous parlons d'applications Web et de création d'API:

Une approche consiste à classer les fichiers par fonctionnalité , un peu à quoi ressemblerait une architecture de micro-service. La plus grande victoire à mon avis est qu'il est très facile de voir quels fichiers se rapportent à une fonctionnalité de l'application.

La meilleure façon d'illustrer est à travers un exemple:

Nous développons une application de bibliothèque. Dans la première version de l'application, un utilisateur peut:

Rechercher des livres et voir les métadonnées des livres
Rechercher des auteurs et voir leurs livres

Dans une deuxième version, les utilisateurs peuvent également:

Créez un compte et connectez-vous
Livres de prêt / emprunt

Dans une troisième version, les utilisateurs peuvent également:

Enregistrer une liste de livres qu'ils souhaitent lire / marquer comme favoris

Nous avons d'abord la structure suivante:

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

Nous ajoutons ensuite les fonctionnalités utilisateur et prêt:

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

Et puis la fonctionnalité des favoris:

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

Pour tout nouveau développeur qui se voit confier la tâche d'ajouter que la recherche de livres doit également renvoyer des informations si un livre a été marqué comme favori, il est très facile de voir où dans le code il doit chercher.

Ensuite, lorsque le propriétaire du produit intervient et s'exclame que la fonctionnalité des favoris doit être complètement supprimée, il est facile de la supprimer.

— maxpaj
source