Project dependencies update, bug fixes, alterations and implementations #158
Conversation
PatrickOtero
requested review from
rigonlucas,
EddieSCJ,
thiagorcode,
wolwerr and
JoaoPauloAmendolaDev
PatrickOtero
changed the title
|
PatrickOtero
changed the title
|
Já notei o PR, devo revisar até o fim da semana. |
|
@PatrickOtero é um PR grande hein, rodei alguns testes localmente aqui e eles falharam, talvez antes de mergear e analisar PR seja bom adicionar a parte de coverage do SonarQube no sistema, ja que ele e free pra open source. O que acha? |
|
Mandei uma mensagem para o @wolwerr para verificarmos a possibilidade, como o PR é muito grande, só o review n traz muita segurança, seria muito útil escrever mais testes e até uns de integração ou e2e, o que podemos fazer junto anyway |
| import { ReportsEntity } from '../../database/entities/reports.entity'; | ||
| import { UsersEntity } from '../../database/entities/users.entity'; | ||
| import { WorkExperiencesEntity } from '../../database/entities/work-experiences.entity'; | ||
| // import { |
There was a problem hiding this comment.
Podemos deletar essa classe comentada?
| @@ -0,0 +1,3 @@ | |||
| export interface IGlobalResponse { | |||
There was a problem hiding this comment.
É uma interface que determina um padrão de resposta nas rotas.
There was a problem hiding this comment.
Cada módulo tem sua própria interface que extende essa interface adicionando suas peculiaridades em relação aos outros.
A gente poderia fazer isso depois de aceitar esse PR? O Mikael (back-end vagas) está esperando essa aprovação pra poder prosseguir com uma tarefa dele. |
Penso que seria interessante fazermos isso depois de estabelecermos o primeiro MVP desse projeto. Ficaríamos menos atolados e enrolados, pois precisaríamos nos preocupar só com os testes e no momento temos a preocupação de fazer o primeiro MVP acontecer. |
Aprovei o PR, todavia, sugiro elaborar mais testes daqui para frente, e repensar se vale a pena usar interfaces de marcação como forma de garantir o contrato das rotas, me parece ser uma complexidade adicional e desnecessária, mas como estou por fora das boas práticas da comunidade typescript, deixo apenas como reflexão. |
Major changes:
1 - All old dependencies were updated.
2 - All breaking changes were solved
Breaking changes:
1 - The typeormConfig is now on a separated file called "data-source.ts" and it is instantiated to be used anywhere on the api
2 - Now the repositories don't extend the Repository class anymore. They are injectable and inside their constructors we need to use the @injectRepository decorator with their entities as a parameter before declaring their private variables containing their repositories instantiated by typeorm. Now the private variables are declared this way:
eg: "private jobsRepository: Repository"
3 - The "ttl" property from the throttler module are now assigned with milliseconds value instead of seconds and are declared inside an attribute called "throttlers" that is an array.
4 - The @throttler decorator arguments now are declared with an object inside an attribute with the name of the target method or controller and that is an object.
Bug Fixes:
1 - The pipe-entity.pipe.ts was an unnecessary file. Its logic was complex and not practic for the project situation. A simplified solution was implemented in all the pipe target files instead.
2 - The company now can list their own jobs with success
Implementations:
1 - IGlobalResponse interface was added to help create a standard for responses in the api. Each module will have its own extended version of this interface.
Alterations:
1 - The "indefinideContract" column was renamed to "openEndedContract"
2 - The "IN_PERSON" enum from "modality" job column was renamed to "ON_SITE"
3 - The route path that lists the specific company's jobs was renamed to "loggedCompanyJobs", now the complete path is: GET /job/loggedCompanyJobs"