Respostas:
Em relação às pastas que você mencionou:
/libs geralmente é usado para customizar classes/functions/modules/vendorou /supportcontém bibliotecas de terceiros (adicionadas como submódulo git ao usar o git como controle de origem)/spec contém especificações para testes BDD./testscontém os testes de unidade de um aplicativo (usando uma estrutura de teste, veja
aqui )NOTA: ambos /vendor e /supportestão obsoletos desde que o NPM introduziu um gerenciamento de pacote limpo. É recomendável lidar com todas as dependências de terceiros usando o NPM e um arquivo package.json
Ao criar um aplicativo bastante grande, recomendo as seguintes pastas adicionais (especialmente se você estiver usando 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 seus modelos de visualização (usando qualquer linguagem de modelo 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 arquivos de imagem/assets/pdf contém arquivos pdf estáticos/css contém folhas de estilo (ou saída compilada por um mecanismo css)/js contém JavaScript do lado do cliente/controllerscontém todas as suas rotas expressas, separadas por módulo / área do seu aplicativo (nota: ao usar a funcionalidade de inicialização do express, essa pasta é chamada /routes)Eu me acostumei a organizar meus projetos dessa maneira e acho que funciona muito bem.
Atualização para aplicativos Express baseados em CoffeeScript (usando connect-assets ):
/app contém seu JavaScript compilado/assets/ contém todos os ativos do lado do cliente que exigem compilação
/assets/js contém seus arquivos CoffeeScript do lado do cliente/assets/css contém todas as folhas de estilo LESS / Stylus/public/(js|css|img) contém seus arquivos estáticos que não são tratados por nenhum compilador/src contém todos os arquivos CoffeeScript específicos do servidor/test contém todos os scripts de teste de unidade (implementados usando uma estrutura de teste de sua escolha)/views contém todas as suas visualizações expressas (seja jade, ejs ou qualquer outro mecanismo de modelagem)Há uma discussão no GitHub por causa de uma pergunta semelhante a esta: https://gist.github.com/1398757
Você pode usar outros projetos para orientação, procure no GitHub por:
E, finalmente, em um livro ( http://shop.oreilly.com/product/0636920025344.do ) sugere esta estrutura:
├── index.html
├── js/
│ ├── main.js
│ ├── models/
│ ├── views/
│ ├── collections/
│ ├── templates/
│ └── libs/
│ ├── backbone/
│ ├── underscore/
│ └── ...
├── css/
└── ...Mais exemplo da minha arquitetura de projeto, você pode 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.
└── testBasicamente, o aplicativo lógico separado para as pastas DB e APP dentro do diretório SRC.
srcou o aplicativo front-end obtém sua própria pasta (com package.jsonestrutura de pastas própria e semelhante)?
Esta é uma resposta indireta, na própria estrutura de pastas, muito relacionada.
Alguns anos atrás, eu tive a mesma pergunta, peguei uma estrutura de pastas, mas precisei mudar muito o diretório mais tarde, porque a pasta foi criada para um propósito diferente do que eu li na internet, ou seja, o que uma pasta específica faz significados diferentes para pessoas diferentes em algumas pastas.
Agora, tendo realizado vários projetos, além da explicação em todas as outras respostas, na própria estrutura de pastas, sugiro seguir a estrutura do próprio Node.js., que pode ser vista em: https://github.com/ nodejs / node . Ele tem ótimos detalhes sobre tudo, digamos linters e outros, que estrutura de arquivos e pastas eles têm e onde. Algumas pastas têm um LEIA-ME que explica o que está nessa pasta.
Iniciar na estrutura acima é bom porque um dia um novo requisito chega e, mas você terá um escopo para melhorar, pois já é seguido pelo próprio Node.js., que é mantido por muitos anos.
Espero que isto ajude.
É importante observar que não há consenso sobre qual é a melhor abordagem e as estruturas relacionadas em geral não impõem nem recompensam certas estruturas.
Acho isso uma sobrecarga enorme e frustrante, mas igualmente importante. É uma espécie de versão subestimada (mas IMO é mais importante) da questão do guia de estilo . Eu gosto de destacar isso porque a resposta é a mesma: não importa qual estrutura você usa, desde que seja bem definida e coerente .
Por isso, proponho procurar um guia abrangente que você goste e deixar claro que o projeto é baseado nisso.
Não é fácil, especialmente se você é novo nisso! Espere passar horas pesquisando. Você encontrará a maioria dos guias recomendando uma estrutura semelhante ao MVC. Embora alguns anos atrás isso possa ter sido uma escolha sólida, hoje em dia esse não é necessariamente o caso. Por exemplo, aqui está outra abordagem .
Supondo que estamos falando de aplicativos da Web e da criação de APIs:
Uma abordagem é categorizar arquivos por recurso , muito parecido com o que seria uma arquitetura de microsserviço. A maior vitória na minha opinião é que é super fácil ver quais arquivos estão relacionados a um recurso do aplicativo.
A melhor maneira de ilustrar é através de um exemplo:
Estamos desenvolvendo um aplicativo de biblioteca. Na primeira versão do aplicativo, um usuário pode:
Em uma segunda versão, os usuários também podem:
Em uma terceira versão, os usuários também podem:
Primeiro, temos a seguinte estrutura:
books
├─ controllers
│ ├─ booksController.js
│ └─ authorsController.js
│
└─ entities
├─ book.js
└─ author.jsEm seguida, adicionamos os recursos de usuário e empréstimo:
user
├─ controllers
│ └─ userController.js
├─ entities
│ └─ user.js
└─ middleware
└─ authentication.js
loan
├─ controllers
│ └─ loanController.js
└─ entities
└─ loan.jsE então a funcionalidade de favoritos:
favorites
├─ controllers
│ └─ favoritesController.js
└─ entities
└─ favorite.jsPara qualquer novo desenvolvedor que receber a tarefa de acrescentar que a pesquisa de livros também deve retornar informações, se algum livro foi marcado como favorito, é realmente fácil ver em que local do código ele deve estar.
Então, quando o proprietário do produto se aproxima e exclama que o recurso de favoritos deve ser removido completamente, é fácil removê-lo.