# Guia de Contribuição

## Desenvolvimento

Para o desenvolvimento, é necessário instalar a versão 10 LTS do Node:

* [Node](https://nodejs.org/en/)

## Debugging

Não é possível realizar o debug de forma simples, para ajudar nesse quesito, o frontend-generator disponibiliza um log que quando um erro ocorre, ele disponibiliza uma stacktrace referente ao arquivo `main.js`(bundle file)

exemplo do arquivo `frontend-generator.log`:
```javascript
2019-06-07T20:34:23.758Z - DEBUG: ReferenceError: entityName is not defined
    at Users\Documents\frontend-generator\bin\main.js:4826:33
    at Array.map (<anonymous>)
```
Portanto, se eu abrir o arquivo `main.js` num editor de texto e ir na linha `4826`, consigo verificar qual método está dando erro e com isso, encontrá-lo dentro dos códigos fontes do frontend-generator para descobrir qual problema está ocorrendo.

## Hot Reload

Para desenvolver e testar as alterações de forma simultânea do frontend-generator, basta executar os seguintes passos

* `cd frontend-generator`
* `npm install (caso ainda não tenha realizado esse passo)`
* `npm link`
* `npm start`

Em outra janela do seu terminal:

* `cd path-do-seu-projeto-de-teste`
* `fg all --force`

Com isso, ao realizar alguma alteração no frontend-generator e regerar o projeto, sempre estará linkado com o seu branch atual.

## Dicas de desenvolvimento

Ao implementar correções/features que refletem nos projetos gerados, recomendo sempre antes implementá-los no projeto gerado e depois começar a passar as implementações para o frontend-generator, isso ajuda pois você consegue primeiro fazer funcionar sem precisar ficar regerando seu projeto a cada alteração.
Para encontrar erros, sugiro seguir os passos descritos em [Debugging](#debugging) e ao encontrar o método que está dando erro, colocar `console.log` para descobrir informações úteis das variaveis que estão com valores inválidos.

## Merge Requests

As alterações devem preferencialmente ser realizadas através de merge requests para o branch `develop`.
Todos os merge requests devem conter o trecho de `CHANGELOG.md` contendo as respectivas explanações da alteração na seção correta:

Exemplo de `CHANGELOG.md` (com os placeholders `{version}` e `{date}`):

`CHANGELOG.md`
```markdown
# {version}
[{date}]

### Quebras de compatibilidade
* [ARQPDT-123](link) - Descrição

### Novas funcionalidades
* [ARQPDT-123](link) - Descrição

### Melhorias
* [ARQPDT-123](link) - Descrição

### Correções
* [ARQPDT-123](link) - Descrição

### Alterações na base de dados
* Descrição

### Alteração de dependências
* dependencia 1.2.3 > 1.2.4
```

## Liberações

As liberações de versões são realizadas através dos [pipelines do projeto](http://git.senior.com.br/arquitetura/frontend-generator/pipelines).

Utilizando o branch `develop`, é possível selecionar três tipos de liberação:
  * `releasePatch`: realiza a liberação de uma versão Patch
  * `releaseMinor`: realiza a liberação de uma versão Minor
  * `releaseMajor`: realiza a liberação de uma versão Major

Todas elas requerem que o `CHANGELOG.md` tenha os placeholders `{version}` e `{date}`, da mesma forma que definido na seção de Merge Requests.