Estrutura de pastas para um nó.projecto js

reparei naquele nó.os projectos js incluem frequentemente pastas como estas:

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

O que significam exactamente? Qual é a diferença entre eles, e onde devo incluir o código referenciado?

 305
node.js
Author: Yves M., 2011-03-03
Source

5 answers

Em relação às pastas que mencionou:

  • /libs é normalmente usado para classes/functions/modulespersonalizado
  • /vendor ou /support contém bibliotecas de terceiros (adicionado como git submódulo ao usar o git como controlo de origem)
  • /spec contém especificações para os testes BDD.
  • /tests contém os ensaios unitários de uma aplicação (utilizando um ensaio quadro, ver Aqui.)

nota: ambos /vendor e /support estão desactualizados desde que o NPM introduziu uma gestão de pacotes limpa. É recomendado lidar com todas as dependências de terceiros usando NPM e um pacote.ficheiro json

Ao construir uma aplicação bastante grande, recomendo as seguintes pastas adicionais (especialmente se estiver a usar algum tipo de Mvc- / ORM-Framework como express ou mangusto):

  • /models contém todos os seus modelos ORM (chamados Schemas em mangusto)
  • /views contém os seus modelos de vista (usando qualquer linguagem de templação suportada no express)
  • /public contém todo o conteúdo estático (imagens, Folhas de estilo, JavaScript do lado do cliente)
    • /assets/images contém ficheiros de imagem
    • /assets/pdf contém ficheiros PDF estáticos
    • /css contém folhas de estilo (ou uma saída compilada por um motor css)
    • /js contém o lado do cliente JavaScript
  • /controllers contém todas as suas rotas expressas, separadas pelo módulo / área da sua aplicação (nota: ao usar a funcionalidade de inicialização do express, esta pasta é chamada /routes)
Habituei-me a organizar os meus projectos desta forma e acho que funciona muito bem.

Actualização para aplicações expresso baseadas no CoffeeScript (usando connect-assets):

  • /app contém o seu JavaScript compilado
  • /assets/ contém todos os activos do lado do cliente que necessitam de compilação
    • /assets/js contém os ficheiros CoffeeScript do lado do seu cliente
    • /assets/css contém todas as suas folhas de estilo menos / Stylus
  • /public/(js|css|img) contém os seus ficheiros estáticos que não são tratados por nenhum compilador
  • /src contém todo o seu CoffeeScript específico do servidor ficheiros
  • /test contém todos os programas de testes unitários (implementados usando uma estrutura de testes à sua escolha)
  • /views contém todas as suas opiniões expressas (seja jade, ejs ou qualquer outro motor template)
 403
Author: schaermu, 2018-06-05 15:21:53
Há uma discussão sobre o GitHub por causa de uma questão semelhante a esta.: https://gist.github.com/1398757

Pode utilizar outros projectos para orientação, procurar no GitHub por:

    Três ânodos.js-na minha opinião, parece ter uma estrutura específica não adequada para cada projecto; Mais leve-uma estrutura mais simples, mas sem um pouco de organização;
E finalmente, num livro. http://shop.oreilly.com/product/0636920025344.do sugere esta estrutura:
  • Índice.html
  • js/
    • principal.js
    • modelos /
    • vistas/
    • colecções/
    • modelos/
    • libs/
      • coluna vertebral/
      • sublinhado/
      • ...
  • css /
  • ...
 44
Author: Paulo Oliveira, 2014-03-17 23:48:30

Mais exemplo da arquitectura do meu projecto podem ver aqui: 

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

Basicamente, a aplicação Lógica foi separada por pastas de DB e aplicações dentro da SRC.

 11
Author: Daniel Chernenkov, 2016-10-15 19:12:49
É importante notar que não há consenso sobre qual é a melhor abordagem e os quadros relacionados em geral não aplicam nem recompensam certas estruturas. Acho isto uma sobrecarga frustrante e enorme, mas igualmente importante. É uma espécie de versão minimizada (mas IMO mais importante) da edição do Guia de estilo . Eu gostaria de salientar isso porque a resposta é a mesma: não importa que Estrutura você usa, desde que esteja bem definido e coerente. Por isso, proponho procurar um guia completo de que gostes e deixar claro que o projecto se baseia nisto. Não é fácil, especialmente se és novo nisto! Espera passar horas a pesquisar. Você vai encontrar a maioria dos guias recomendando uma estrutura MVC-like. Embora há vários anos isso possa ter sido uma escolha sólida, hoje em dia isso não é necessariamente o caso. Por exemplo Aqui está outra abordagem.
 1
Author: thisismydesign, 2017-12-22 18:14:53

Esta é a resposta indirecta, na própria estrutura de pastas, muito relacionada.

Alguns anos atrás eu tive a mesma pergunta, tomou uma estrutura de pastas, mas tive que fazer um monte de diretório movendo-se mais tarde, porque a pasta foi feito para uma finalidade diferente da que eu li na internet, que é, o que uma determinada pasta não tem significados diferentes para pessoas diferentes em algumas pastas.

Agora, tendo feito vários projetos, além de explicações em todas as outras respostas, estrutura de pasta em si, eu sugeriria fortemente para seguir a estrutura do nó.js em si, que pode ser visto em: https://github.com/nodejs/node . ele tem um grande detalhe em todos, diga linters e outros, que Arquivo e estrutura de pastas que eles têm e onde. Algumas pastas têm um README que explica o que está nessa pasta.

Começar em cima da estrutura é bom porque algum dia um novo requisito entra e mas você terá um escopo para melhorar como ele já é seguido por nó.js em si mesma, que se mantém há muitos anos.

Espero que isto ajude.
 0
Author: Manohar Reddy Poreddy, 2017-11-04 04:52:34