Convenções de nomenclatura de projetos Node.js para arquivos e pastas

Quais são as convenções de nomenclatura para arquivos e pastas em um grande projeto Node.js.

Devo capitalizar, camelCase ou subestimar?

Ou seja, isso é considerado válido?

project-name
    app
        controllers
            someThings.js
            users.js
        models
                someThing.js
                user.js
        views
            some-things
                index.jade
            users
                logIn.jade
                signUp.jade
    ...

Depois de alguns anos com nó, posso dizer que existem há convenções para a estrutura de diretório / arquivo. No entanto, a maioria dos aplicativos express (profissionais) usam uma configuração como:

/
  /bin - scripts, helpers, binaries
  /lib - your application
  /config - your configuration
  /public - your public files
  /test - your tests

Um exemplo que usa essa configuração é nodejs-starter .

Eu pessoalmente mudei essa configuração para:

/
  /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

Na minha opinião, o último combina melhor com a estrutura de diretórios no estilo Unix (enquanto o primeiro mistura isso um pouco).

Também gosto desse padrão para separar arquivos:

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;

lib / static / index.js

var express = require('express');

module.exports = function(app) {

  app.use(express.static(app.settings.static.path));

};

Isso permite separar perfeitamente todo o código-fonte sem ter que incomodar as dependências. Uma solução realmente boa para combater o Javascript desagradável. Um exemplo do mundo real próximo, que usa essa configuração.

Atualizar (nomes de arquivos):

Em relação aos nomes de arquivo, os mais comuns são nomes de arquivo curtos e em minúsculas . Se o seu arquivo só pode ser descrito com duas palavras, a maioria dos projetos JavaScript usa um sublinhado como delimitador.

Atualizar (variáveis):

Com relação às variáveis, as mesmas "regras" se aplicam aos nomes de arquivos. Protótipos ou classes, no entanto, devem usar camelCase .

Atualização (guias de estilo):

• https://github.com/feross/standard
• https://github.com/airbnb/javascript

Use kebab-casepara todos os nomes de pacotes, pastas e arquivos.

Por quê?

Você deve imaginar que qualquer pasta ou arquivo pode ser extraído para seu próprio pacote algum dia. Os pacotes não podem conter letras maiúsculas.

Os novos pacotes não devem ter letras maiúsculas no nome. https://docs.npmjs.com/files/package.json#name

Portanto, camelCasenunca deve ser usado. Isso deixa snake_casee kebab-case.

kebab-caseé de longe a convenção mais comum hoje. O único uso de sublinhados é para pacotes de nós internos, e isso é simplesmente uma convenção desde os primeiros dias.

Não existem convenções. Existem algumas estruturas lógicas.

A única coisa que posso dizer: nunca use nomes de arquivos e diretórios camelCase. Por quê? Funciona, mas no Mac e no Windows não há diferença entre someAction e alguma ação. Eu conheci esse problema, e não uma vez. Eu exigi um arquivo como este:

var isHidden = require('./lib/isHidden');

Mas, infelizmente, eu criei um arquivo com cheio de minúsculas: lib/ishidden.js. Funcionou para mim no mac. Funcionou bem no mac do meu colega de trabalho. Os testes são executados sem erros. Após a implantação, recebemos um grande erro:

Error: Cannot find module './lib/isHidden'

Oh sim. É uma caixa Linux. Portanto, a estrutura de diretórios do camelCase pode ser perigosa. É o suficiente para um colega que está desenvolvendo no Windows ou Mac.

Portanto, use o separador de sublinhado (_) ou traço (-), se necessário.

Baseado no ' Guia de estilo do Google JavaScript '

Os nomes dos arquivos devem ser todos minúsculos e podem incluir sublinhados (_) ou travessões (-), mas nenhuma pontuação adicional. Siga a convenção que seu projeto usa. A extensão dos nomes de arquivo deve ser .js.

A maioria das pessoas usa camelCaseem JS. Se você quiser abrir o código de algo, sugiro que use este :-)

Node.js não impõe nenhuma convenção de nomenclatura de arquivo (exceto index.js). E a linguagem Javascript em geral também não. Você pode encontrar dezenas de tópicos aqui que sugerem camelCase, hífens e sublinhados, qualquer um dos quais funciona perfeitamente bem. Então a escolha é sua. Escolha um e fique com ele.

De acordo com mim: Para arquivos, use a caixa de camelo inferior se module.exports for um objeto, quero dizer um módulo singleton. Isso também se aplica a arquivos JSON, pois eles também são de uma forma única. Use maiúsculas e minúsculas se module.exports retornar uma função construtora onde atua como uma classe.

Para pastas, use nomes curtos. Se houver necessidade de várias palavras, deixe-as totalmente em minúsculas separadas por "-" para que funcione em todas as plataformas de forma consistente.