-
Notifications
You must be signed in to change notification settings - Fork 0
Chore/configure blueprint #1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
…l disponivel a partir da versao 10
…tação do softDelete
…ls já existentes no projeto
|
eu esperava nao depender mais dos comentários no arquivo de rotas. Acredito que seja pra colocar no lugar certo, mas acho melhor manter limpo e ter o ínfimo trabalhinho manual de mudar a linha de lugar. Só minha opinião, se outros discordarem posso me adequar tranquilamente à opinião divergente. |
|
ao definir os nomes dos atributos do model, seria interessante usar sempre lower_snake_case, que é como esperamos os dados na base de dados, mesmo que o dev (vulgo, usuário) escreva em quAlquER-CasE poderiamos transformar para o esperado |
|
vi que o wrap que ta sendo colocado por padrão no resource de collections é null, deveria ser |
|
o trait softDeletes usado nos models mongo deveria ser: |
|
ele tá criando migrations, deveria? acredito que não é um problemão, posso apagar toda vez que gerar, mas se nem criar já é uma coisa a menos. 😬 |
|
os testes gerados estão falhando, como as rotas são definidas no espaço protegido pelo auth, nos testes deveria usar o actingAs para usar um acesso logado. Os testes que esperam códigos de sucesso falham porque recebem 401 Unauthenticated |
|
sugiro, que, se possível, seja trocado nos testes o uso de assertStatus(###) para os respectivos assertOk, assertCreated, assertNoContent, etc... |
|
os testes de created deveriam olhar a base para assegurar que o registro foi criado, apenas a resposta do controller não garante o funcionamento, um método de controller vazio, retorna 200, sem fazer absolutamente nada |
… comentarios setados
… de variaveis informadas
…ir testabiliade mais field

O que foi feito?
Implementação do comando principal cuids:generate, responsável por orquestrar a geração de módulos CUIDS (MongoDB) utilizando o Laravel Blueprint.
Alterações principais
Obs: O comando utilizou como base o Cuids Generator (Backend) que já estava em funcionamento no Keldor
Dependências adicionadas
Testando
Adicione o repositório em seu
composer.jsonPara executar uma branch específica, execute o seguinte comando:
Caso o projeta ja tenha configurado o cuids:generator antigo, comentar ou alterar o nome do comando para não chocar com o do pacote.
Execute o comando: