Setup de projetos (boilerplate)

[nayarahilton]

Olá 😊
Decidi montar um boilerplate para facilitar a vida dos meus projetos pessoais e fiquei com muitas dúvidas a respeito de quais ferramentas utilizar.
Como queria algo bem simples, acabei optando por usar apenas npm scripts e fiz uma mistureba de estruturas que sei lá haha.
Aqui está, caso alguém queira opinar(ainda está em desenvolvimento):
https://github.com/nayarahilton/atomicat-boilerplate

Agora, no trabalho, vou precisar refazer o setup de um projeto e com isso surgiram novas dúvidas. É um projeto grande e que só tende a crescer. Será todo baseado em componentes. Preciso que seja super consistente e com a menor probabilidade de erros possível.

Ai me pergunto:
Template engine: handlebars, nunjucks, ejs, etc? Module bundler: webpack, browserify, etc? Task runner ou apenas npm scripts?

Estrutura: Atomic design, componentes/módulos, pasta do componente com todos os arquivos necessários(styl, js, hbs) ou uma pasta para cada tipo de arquivo?

Enfim, muitas e muitas dúvidas. Principalmente na parte estrutural.
Gostaria de saber a experiência de vocês com projetos grandes, principalmente. Qual funcionou melhor e qual gerou problemas futuros.

Assim ja repenso meu boilerplate pessoal e fico mais segura nas decisões que vou tomar para refazer o setup desse projeto 😎

[guilhermejcgois]

Você conhece o Yeoman, @nayarahilton ? Ele trabalha com o que ele chama de generator para fazer o scaffolding de projetos, acho bacana e simples de usar, também não é difícil fazer seu próprio generator, se quiser saber mais o site dele é esse aqui. Você pode inclusive fazer um generator interativo para o usuário escolher se ele quer handlebars, nunjucks ou ejs, por exemplo.

[nayarahilton]

@guilhermejcgois Já tinha ouvido falar, mas nunca usei. Vou dar uma estudada :D Obrigada!

[doug2k1]

A respeito de task runners, minha opinião (um pouco opinião e um pouco experiência) é que NPM scripts + Webpack resolve praticamente tudo. Grunt e Gulp tiveram as últimas versões lançadas há mais de um ano (Gulp 4 tá no beta eterno) e os plugins tendem a seguir esse caminho.
O ecossistema de NPM com Webpack tá mais ativo, e para novos projetos eu iria nesse caminho.

[skvggor]

@nayarahilton, atualmente estou meio que fazendo isso também: montando um boilerplate (ou algo assim rs) usando http://gohugo.io/. Não está muito diferente do que você fez - ainda está uma bagunça no meu caso.

• https://github.com/stillas/stillas (somente prepara um novo projeto)
• https://github.com/stillas/theme (aqui ficam as coisas do hugo theme)

Curti bastante o que seu projeto. Juntou as 'melhores' ferramentas e organizou tudo num repo bem documentado.

[adrianoenache]

Olá

Acho que a resposta certa é que não existe uma resposta certa.

Cada projeto, equipe, empresa tem a sua metodologia e ferramentas preferidas/necessárias e cada um vai puxar a sardinha para o seu lado. E pelo ponto de vista de cada uma destas pessoas a dele vai ser a sétima maravilha do mundo.

Mas qual metodologia/ferramenta é a melhor?

Te digo que vai ser aquela com que você tiver mais afinidade e facilidade.

Porém uma coisa que você deve levar em consideração quanto mais simples melhor, quanto menos dependências melhor, quanto menor o setup melhor. O importante é você se sentir confortável, estudar e dominar as ferramentas escolhidas para o seu projeto.

Seja a tecnologia que escolher aposte nela e torne-se especialista no assunto. No nosso ramo todo mês, talvez menos, tem uma tecnologia nova sendo vendida como a melhor e até talvez seja, talvez não.

Mas tudo isso que eu disse até agora é em relação ao seus projetos pessoais.

Agora sobre o trabalho ... um projeto grande, com muitos componentes e escalável ...

Vale conversar com a equipe com quem vai trabalhar para definir as ferramentas/metodologia, afinal não adianta muito definir coisas que a equipe não domina ou conhece pouco.

Abs

[felipefialho]

Acho que a definição de um boilerplate pode ser dividida em duas frentes: Metodologia e tecnologia.

Metodologia

Atomic design, componentes/módulos, pasta do componente com todos os arquivos necessários(styl, js, hbs) ou uma pasta para cada tipo de arquivo?

Também sou fã de Atomic Design e uso faz muitos anos (desde 2013 acho), continuo achando que funciona muito bem, especialmente em projetos estáticos.

Porém o @Xhamps me alertou para um ponto que me fez refletir: Ao trabalhar com Atomic Design em equipe, a definição do que é um atom, molecule ou organism pode variar entre as pessoas do time e isso gera dois problemas:

• O primeiro é justamente para encontrar o componente dentro dessa estrutura, já que como nem sempre foi você que adicionou determinado componente, ele pode estar uma pasta diferente da que você vê sentido.
• O segundo, quase igual o primeiro, é que acaba gerando uma complexidade na hora de criar ou alterar o componente, a equipe meio que precisaria decidir o tempo todo em que pasta adicionar quando o objetivo daquele componente não ficar claro. Então ocorre uma quebra no fluxo.

Sendo assim, optamos aqui no Cubo por não usar Atomic Design e adicionar os componentes soltos dentro de uma pasta de componentes. Por outro lado, continuo achando que para projetos estáticos menos complexos (geralmente sem SPA envolvido) ou projetos que vou trabalhar sozinho, é uma estrutura super ágil e que funciona muito bem.

Outro ponto é sobre a própria organização dos arquivos. Aqui tenho certeza que independente da metodologia escolhida (Atomic Design ou não por exemplo) separar tudo que é relacionado ao componente dentro da própria pasta faz mais sentido pelo mesmo motivo que isolar as media queries no próprio componente faz muito sentido.

Tecnologia

Template engine: handlebars, nunjucks, ejs, etc? Module bundler: webpack, browserify, etc? Task runner ou apenas npm scripts?

Ainda estou usando o Gulp na maioria dos projetos por motivos de pura preguiça e porque continua funcionando. Mas como o @doug2k1 disse, NPM Scripts + Webpack resolvem tudo atualmente, e é nisso que focaria caso estivesse criando meu boilerplate hoje (ou quando decidir por atualizar o meu).

Ter menos dependências é vantajoso por vários aspectos: Curva de aprendizado menor, menos coisas rodando em paralelo, manutenção mais fácil, etc.

Template Engine, vai muito do que você se sente mais confortável, não tem certo ou errado, é pura escolha. Mas evitaria usar se forem simples demais e não tiver coisas básicas como if ou for, porque vai te obrigar a usar outras dependências para resolver esse problema.

Module Bundler, usaria o Webpack por ser muito poderoso e já auxiliar como task runner.

---

Finalizando, não é incomum ter vários boilerplates e usar conforme a necessidade do projeto, por exemplo ter um que é puramente para projetos estáticos, outro para usar em conjunto com SPAs, etc.

Nesse caso, o Yeoman citado pelo @guilhermejcgois ou o Slush podem auxiliar nisso.

[Javiani]

@nayarahilton

Nayaraaation, posso deixar minhas sugestões também? Concordo com algumas coisas que o Fialho disse e o Adriano, mas queria deixar uma síntese do que acredito.

O boilerplate hoje, na minha concepção, não é apenas para iniciar um projeto. Ele serve também como uma ferramenta para o acúmulo de aprendizado, pense que pode ir incrementando/atualizando conforme vai aprendendo ferramentas novas ou modelos/técnicas novas.

O grande problema do boilerplate é que ele vai estar sempre desatualizado, ele cai no mesmo problema que temos quando terminamos um projeto e sentimos que poderíamos refazer e torná-lo melhor.

A minha sugestão seria o seguinte:

Monte um Boilerplate básico o mais simples que puder, apenas com as ferramentas necessárias para fazer o projeto rodar, com as ferramentas que possui familiaridade, para fazer uma landing page básica e deixe ele na Master.

Se quiser ir incrementando o Boilerplate, você pode criar novos branches, que podem ser orfãos e que nunca serão mergeados na master :

• (master) Boilerplate
• (branch) Boilerplate-nunjucks
• (branch) Boilerplate-nivel-hard
• (branch) Boilerplate-fullstack
• (branch) Boilerplate-esbrobles

O nome fica por sua conta, mas poderia ir criando branches que nada mais são que versões mais complexas/incrementadas do seu Boilerplate original.

Assim, você consegue criar vários boilerplates que irão servir como lugar para aprendizado e opções para os diferentes tipos de problemas que poderá enfrentar, sem usar ferramentas complexas, apenas os branches do github pra isso.

[renatorib]

Estou pelo celular e é ruim escrever muito, mas vou participar dando minha opinião, mesmo que sem detalhar muito.

Vou partir da visão de que "eu preciso fazer um projeto, o que vou escolher?"

Task Runners:
Já faz um pouco mais de um ano que não uso mais Gulp, apesar de ainda achar ele muito bom, simplesmente não vejo mais tanta utilidade quando você tem o npm scripts + module bundler.

Template engine:
Bom, devido à meu grau de intimidade com React, por trabalhar com ele já há quase dois anos, acho que se eu fosse ter que escolher um seria o React. Muitos esquecem que React é uma lib de UI e o tratam como um framework pra SPA erroneamente. Aquele ditado: "a melhor ferramenta é aquela que você sabe usar". Eu acabaria criando um layout com React e dando um renderToString pra gerar os htmls, este seria minha lternativa à um handlebars/nunjucks se eu precisasse de um template engine hoje (gerar html).

Mas também já trabalhei com outros como o próprio handlebars, se tivesse que ser também não teria problema.

Module bundler:
Se eu tivesse criando uma aplicação, usaria o Webpack. Se eu tivesse criando uma lib, usaria o rollup.
Basicamente os dois caras que costumo usar. Porém tem um cara bem bacana que tá nascendo aí e é legal ficar de olho: FuseBox. Parece que é mais fácil e mais rápido que o Webpack. Vale investir um tempo pra dar uma olhada nele (preciso também)

Estrutura:
Eu particularmente gosto de separar de uma maneira mais modular, isto é "um pacote fechado", por exemplo:

Estrutura A: (por arquivo)

estilos/
  button.css
  input.css
templates/
  button.tpl
  input.tpl

Estrutura B: (por componente)

componentes/
  input/
    input.css
    input.tpl
  button/
    button.css
    button.tpl

O jeito A até que funciona, se for um negócio simples, não deixem que te digam que é errado. O problema é que ele não escala muito bem, já o jeito B escala bem melhor, então conforme as coisas crescem, faz mais sentido (e mais saudável) o B. E como o jeito B também faz total sentido pra projetos pequenos, acabo que sempre vou pro B mesmo. O jeito A, pelo menos pra mim, nunca uso.

Se chegar à um ponto de ser muito maior, aí o lance é separar por módulos de funcionalidade.

components/ ("globais") 
modules/
  account/
     components/
       userbar/
       login/
       profile/
  products/
    components/
      product-card/
      ... 
  checkout/
     components/
       ... 

É tudo uma questão de maintainability: escalabilidade. Não há um jeito errado, mas sim jeitos mais fáceis de manter. Choose one.

Mas essa parte eu acho que varia muito da escolha pessoal também. Pode servir de inspiração, dica, conselho, mas nunca regra.

Conclusão:
Se você perceber, cada escolha tem um motivo, e na maioria das vezes costuma ser: conhecimento ou intimidade com a tecnologia (React), adequação ao projeto (Webpack ou Rollup), avaliar as necessidades dentro de um contexto (Npm scripts ao invés de Gulp, por exemplo) e por último, mas não menos importante, gosto pessoal (Estrutura).

Como já citei ali em cima, a melhor ferramenta é o a que você já sabe. Muitos discutem que X é melhor que Y e vice-versa. É óbvio que se você já sabe X, este vai ser a melhor escolha pra você e para o projeto. Evita a curva de aprendizagem e já tem know-how pra lidar com problemas que possam aparecer.

Em geral, nunca entre de cabeça em algo que você nunca usou antes e que possa se arrepender depois, a não ser que seja projeto pessoal e o tempo não seja um problema, ou você estiver criando algo pra estudar, por exemplo. Pois se for um projeto da empresa, freela, etc, pode afetar as entregas.

Aliás, tenho sempre pra mim que testar coisas novas é em projetos pessoais e em projetos de estudo.
E dentro da empresa: talvez pra MVPs, PoCs e em sisteminhas pequenos de uso interno.