Estrutura de pastas para um nó.projecto js
reparei naquele nó.os projectos js incluem frequentemente pastas como estas:
O que significam exactamente? Qual é a diferença entre eles, e onde devo incluir o código referenciado?/ libs, / vendor, /support, /spec, / tests
5 answers
Em relação às pastas que mencionou:
-
/libs
é normalmente usado paraclasses/functions/modules
personalizado -
/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 (chamadosSchemas
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
)
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)
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;
- Índice.html
- js/
- principal.js
- modelos /
- vistas/
- colecções/
- modelos/
- libs/
- coluna vertebral/
- sublinhado/
- ...
- css /
- ...
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.
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.