Estructura de carpetas para un proyecto Node.js

346

Noto que los proyectos de Node.js a menudo incluyen carpetas como estas:

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

¿Qué significan exactamente estos? ¿Cuál es la diferencia entre ellos y dónde debo incluir el código referenciado?

node.js

— guilin 桂林
fuente

439

Con respecto a las carpetas que mencionó:

/libs generalmente se usa para personalizar classes/functions/modules
/vendoro /supportcontiene bibliotecas de terceros (agregadas como submódulo git cuando se usa git como control de fuente)
/spec contiene especificaciones para pruebas de BDD.
/testscontiene las pruebas unitarias para una aplicación (usando un marco de prueba, ver aquí )

NOTA: ambos /vendory /supportestán en desuso desde que NPM introdujo una administración de paquetes limpia. Se recomienda manejar todas las dependencias de terceros utilizando NPM y un archivo package.json

Al crear una aplicación bastante grande, recomiendo las siguientes carpetas adicionales (especialmente si está utilizando algún tipo de MVC- / ORM-Framework como express o mangosta ):

/modelscontiene todos sus modelos ORM (llamados Schemasen mangosta)
/views contiene sus plantillas de vista (usando cualquier lenguaje de plantillas compatible con express)
/public contiene todo el contenido estático (imágenes, hojas de estilo, JavaScript del lado del cliente)
- /assets/images contiene archivos de imagen
- /assets/pdf contiene archivos pdf estáticos
- /css contiene hojas de estilo (o salida compilada por un motor css)
- /js contiene JavaScript del lado del cliente
/controllerscontiene todas sus rutas express, separadas por el módulo / área de su aplicación (nota: cuando se utiliza la funcionalidad de arranque de express, se llama a esta carpeta /routes)

Me acostumbré a organizar mis proyectos de esta manera y creo que funciona bastante bien.

Actualización para aplicaciones Express basadas en CoffeeScript (usando connect-assets ):

/app contiene tu JavaScript compilado
/assets/ contiene todos los activos del lado del cliente que requieren compilación
- /assets/js contiene sus archivos CoffeeScript del lado del cliente
- /assets/css contiene todas sus hojas de estilo MENOS / Stylus
/public/(js|css|img) contiene sus archivos estáticos que no son manejados por ningún compilador
/src contiene todos sus archivos específicos de CoffeeScript del lado del servidor
/test contiene todos los scripts de prueba de unidad (implementado usando un marco de prueba de su elección)
/views contiene todas sus vistas expresas (ya sea jade, ejs o cualquier otro motor de plantillas)

— schaermu
fuente

55

¿dónde pondrías tus js, css, imágenes del lado del cliente? ¿Sugeriría una estructura de carpetas similar en la carpeta pública, como: 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 crea un directorio ./routes, ¿es eso lo mismo que ./controllers en su ejemplo?

— chovy

2

¿Por qué no creas un generador Yeoman con esa propuesta? Podría convertirse en un estándar.

— Jayr Motta

+1 Viniendo de ASP.NET MVC, llamar a la carpeta "rutas" "controladores" tiene mucho más sentido para mí.

— adam0101

Pregunta, ¿no son las estructuras de directorio generadas normalmente por el marco (es decir, Symfony para PHP)? Con Express, por ejemplo, ¿no se crea una estructura de directorio correcta? los desarrolladores deben crear y mantener manualmente el diseño y las rutas de MVC? Agradezco cualquier comentario, soy nuevo en Express

— AnchovyLegend

49

Hay una discusión sobre GitHub debido a una pregunta similar a esta: https://gist.github.com/1398757

Puede usar otros proyectos como guía, busque en GitHub para:

ThreeNodes.js: en mi opinión, parece tener una estructura específica que no es adecuada para cada proyecto;
más ligero: una estructura más simple, pero carece de un poco de organización;

Y finalmente, en un libro ( http://shop.oreilly.com/product/0636920025344.do ) sugiere esta estructura:

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

— Paulo Oliveira
fuente

Creé un módulo para requerir archivos dinámicamente, lo que le permite estructurar su proyecto por función en lugar del típico Modelo, Vista, Controlador. Espero que ayude a alguien: github.com/ssmereka/crave

— Scott

13

Más ejemplos de la arquitectura de mi proyecto que puedes ver aquí:

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

Básicamente, la aplicación lógica se separó a las carpetas DB y APP dentro del directorio SRC.

— Daniel Chernenkov
fuente

si su aplicación también contiene una aplicación front-end, ¿la coloca debajo srco la aplicación front-end obtiene su propia carpeta (con su propia package.jsonestructura de carpetas y similar)?

— wal

2

@wal Prefiero separar los proyectos frontend a otro repositorio ya que está más organizado

— Daniel Chernenkov

2

Esta es una respuesta indirecta, en la estructura de la carpeta, muy relacionada.

Hace unos años tuve la misma pregunta, tomé una estructura de carpetas pero tuve que hacer un gran movimiento de directorios más adelante, porque la carpeta estaba destinada a un propósito diferente al que he leído en Internet, es decir, lo que una carpeta en particular tiene diferentes significados para diferentes personas en algunas carpetas.

Ahora, habiendo realizado múltiples proyectos, además de la explicación en todas las otras respuestas, sobre la estructura de la carpeta en sí, sugeriría encarecidamente seguir la estructura del propio Node.js, que se puede ver en: https://github.com/ nodejs / node . Tiene gran detalle sobre todos, digamos linters y otros, qué estructura de archivos y carpetas tienen y dónde. Algunas carpetas tienen un archivo README que explica qué hay en esa carpeta.

Comenzar en la estructura anterior es bueno porque algún día entra un nuevo requisito y tendrá un margen para mejorar, ya que ya lo sigue Node.js, que se mantiene durante muchos años.

Espero que esto ayude.

— Manohar Reddy Poreddy
fuente

1

Es importante tener en cuenta que no hay consenso sobre cuál es el mejor enfoque y los marcos relacionados en general no imponen ni recompensan ciertas estructuras.

Considero que esto es una sobrecarga frustrante y enorme, pero igualmente importante. Es una especie de versión minimizada (pero IMO más importante) del tema de la guía de estilo . Me gusta señalar esto porque la respuesta es la misma: no importa qué estructura uses siempre y cuando esté bien definida y sea coherente .

Por lo tanto, propongo buscar una guía completa que le guste y dejar en claro que el proyecto se basa en esto.

¡No es fácil, especialmente si eres nuevo en esto! Espere pasar horas investigando. Encontrarás la mayoría de las guías que recomiendan una estructura similar a MVC. Si bien hace varios años esa podría haber sido una opción sólida, hoy en día ese no es necesariamente el caso. Por ejemplo, aquí hay otro enfoque .

— este es mi diseño
fuente

1

Suponiendo que estamos hablando de aplicaciones web y creación de API:

Un enfoque consiste en clasificar los archivos por características , de forma muy similar a la arquitectura de un micro servicio. La mayor victoria en mi opinión es que es muy fácil ver qué archivos se relacionan con una característica de la aplicación.

La mejor manera de ilustrar es a través de un ejemplo:

Estamos desarrollando una aplicación de biblioteca. En la primera versión de la aplicación, un usuario puede:

Busque libros y vea metadatos de libros
Buscar autores y ver sus libros.

En una segunda versión, los usuarios también pueden:

Crea una cuenta e inicia sesión
Préstamo / préstamo de libros

En una tercera versión, los usuarios también pueden:

Guardar una lista de libros que quieren leer / marcar favoritos

Primero tenemos la siguiente estructura:

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

Luego agregamos las características de usuario y préstamo:

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

Y luego la funcionalidad de favoritos:

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

Para cualquier desarrollador nuevo que se le entregue la tarea de agregar que la búsqueda de libros también debe devolver información si algún libro ha sido marcado como favorito, es realmente fácil ver en qué parte del código debe buscar.

Luego, cuando el propietario del producto entra y exclama que la función de favoritos debe eliminarse por completo, es fácil eliminarla.

— maxpaj
fuente