Estrutura de pastas para um projeto Node.js

Eu noto que os projetos do Node.js geralmente incluem pastas como estas:

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

O que exatamente isso significa? Qual é a diferença entre eles e onde devo include código referenciado?

Sobre as pastas que você mencionou:

  • /libs é geralmente usado para classs/functions/modules
  • /vendor ou /support contém bibliotecas de terceiros (adicionadas como sub-módulo git ao usar o git como controle de origem)
  • /spec contém especificações para testes de BDD.
  • /tests contém os /tests unitários para uma aplicação (usando uma estrutura de teste, veja aqui )

NOTA: ambos /vendor e /support estão obsoletos, pois o NPM introduziu um gerenciamento de pacotes limpo. É recomendado lidar com todas as dependencies de terceiros usando o NPM e um arquivo package.json

Ao criar um aplicativo bastante grande, eu 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 in mongoose)
  • /views contém seus modelos de visualização (usando qualquer linguagem de templates 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
  • /controllers contém todas as suas rotas expressas, separadas por módulo / área da sua aplicação (nota: ao usar a funcionalidade bootstrapping do express, esta 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 resources do lado do cliente que exigem compilation
    • /assets/js contém seus arquivos CoffeeScript do lado do cliente
    • /assets/css contém todas as suas folhas de estilo LESS / Stylus
  • /public/(js|css|img) contém seus arquivos estáticos que não são manipulados por nenhum compilador
  • /src contém todos os seus arquivos CoffeeScript específicos do lado 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 sobre o GitHub por causa de uma pergunta semelhante a esta: https://gist.github.com/1398757

Você pode usar outros projetos para orientação, pesquise no GitHub para:

  • ThreeNodes.js – na minha opinião, parece ter uma estrutura específica não adequada para todos os projetos;
  • mais leve – uma estrutura mais simples, mas falta um pouco de organização;

E finalmente, em um livro ( http://shop.oreilly.com/product/0636920025344.do ) sugere essa estrutura:

  • index.html
  • js /
    • main.js
    • modelos /
    • visualizações /
    • collections /
    • modelos/
    • libs /
      • espinha dorsal/
      • sublinhado /
  • 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. └── test 

Basicamente, o aplicativo lógico separado para as pastas DB e APP dentro do diretório SRC.

É importante notar que não há consenso sobre qual é a melhor abordagem e estruturas relacionadas em geral não reforçam nem recompensam certas estruturas.

Acho que isso é uma sobrecarga frustrante e enorme, mas igualmente importante. É uma espécie de versão menosprezada (mas IMO mais importante) da questão do guia de estilo . Eu gosto de mostrar isso porque a resposta é a mesma: não importa qual estrutura você usa, desde que seja bem definida e coerente .

Então eu 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 do tipo MVC. Embora há vários anos isso possa ter sido uma escolha sólida, hoje em dia não é necessariamente o caso. Por exemplo, aqui está outra abordagem .

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 tive que fazer um diretório muito mais tarde, porque a pasta era para um propósito diferente do que eu li na internet, ou seja, o que uma pasta particular tem significados diferentes para pessoas diferentes em algumas pastas.

Agora, tendo feito vários projetos, além da explicação em todas as outras respostas, na própria estrutura de pastas, sugiro fortemente seguir a estrutura do próprio Node.js, que pode ser visto em: https://github.com/ nodejs / node . Tem grande detalhe em todos, digamos linters e outros, que estrutura de arquivos e pastas eles têm e onde. Algumas pastas têm um README que explica o que está nessa pasta.

Começar na estrutura acima é bom porque algum dia um novo requisito vem e você terá um escopo para melhorar, pois ele já é seguido pelo próprio Node.js que é mantido por muitos anos.

Espero que isto ajude.