este problema se puede solucionar de diversas formas, pero te mostramos la resolución más completa para nosotros.
Solución:
Después de algunos años con node, puedo decir que hay no convenciones para la estructura de directorios/archivos. Sin embargo, la mayoría de las aplicaciones express (profesionales) usan una configuración como:
/
/bin - scripts, helpers, binaries
/lib - your application
/config - your configuration
/public - your public files
/test - your tests
Un ejemplo que usa esta configuración es nodejs-starter.
Yo personalmente cambié esta configuración a:
/
/etc - contains configuration
/app - front-end javascript files
/config - loads config
/models - loads models
/bin - helper scripts
/lib - back-end express files
/config - loads config to app.settings
/models - loads mongoose models
/routes - sets up app.get('..')...
/srv - contains public files
/usr - contains templates
/test - contains test files
En mi opinión, este último combina mejor con la estructura de directorios estilo Unix (mientras que el primero mezcla esto un poco).
También me gusta este patrón para separar archivos:
lib/index.js
var http = require('http');
var express = require('express');
var app = express();
app.server = http.createServer(app);
require('./config')(app);
require('./models')(app);
require('./routes')(app);
app.server.listen(app.settings.port);
module.exports = app;
libre/static/index.js
var express = require('express');
module.exports = function(app)
app.use(express.static(app.settings.static.path));
;
Esto permite desacoplar perfectamente todo el código fuente sin tener que preocuparse por las dependencias. Una muy buena solución para luchar contra Javascript desagradable. Un ejemplo del mundo real está cerca que utiliza esta configuración.
Actualización (nombres de archivo):
En cuanto a los nombres de archivo, los más comunes son corto, minúsculas nombres de archivo Si su archivo solo se puede describir con dos palabras, la mayoría de los proyectos de JavaScript usan un guión bajo como delimitador.
Actualización (variables):
Con respecto a las variables, se aplican las mismas “reglas” que para los nombres de archivo. Los prototipos o clases, sin embargo, deben usar el caso de Carmel.
Actualización (guías de estilo):
- https://github.com/feross/estándar
- https://github.com/airbnb/javascript
Usar kebab-case para todos los nombres de paquetes, carpetas y archivos.
¿Por qué?
Debería imaginar que cualquier carpeta o archivo podría extraerse a su propio paquete algún día. Los paquetes no pueden contener letras mayúsculas.
Los paquetes nuevos no deben tener letras mayúsculas en el nombre. https://docs.npmjs.com/files/package.json#nombre
Por lo tanto, camelCase nunca debe usarse. esto deja snake_case y kebab-case.
kebab-case es, con mucho, la convención más común en la actualidad. El único uso de guiones bajos es para paquetes de nodos internos, y esto es simplemente una convención de los primeros días.
No hay convenciones. Hay alguna estructura lógica.
Lo único que puedo decir: nunca use los nombres de archivos y directorios camelCase. ¿Por qué? Funciona, pero en Mac y Windows no hay diferencia entre someAction y some action. Me encontré con este problema, y no una vez. Necesito un archivo como este:
var isHidden = require('./lib/isHidden');
Pero lamentablemente creé un archivo lleno de minúsculas: lib/ishidden.js. Funcionó para mí en mac. Funcionó bien en Mac de mi compañero de trabajo. Las pruebas se ejecutan sin errores. Después de la implementación, obtuvimos un gran error:
Error: Cannot find module './lib/isHidden'
Oh sí. Es una caja de linux. Entonces, la estructura del directorio camelCase podría ser peligrosa. Es suficiente para un colega que está desarrollando en Windows o Mac.
Así que use un guión bajo (_) o un guión (-) como separador si lo necesita.
Puntuaciones y comentarios
Si conservas alguna incertidumbre y forma de acrecentar nuestro división puedes escribir un comentario y con mucho gusto lo ojearemos.