Project dependencies update, bug fixes, alterations and implementations

[PatrickOtero]

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"

[sonarcloud[bot]]

Quality Gate passed

Issues
0 New issues

Measures
0 Security Hotspots
No data about Coverage
No data about Duplication

See analysis details on SonarCloud

[EddieSCJ]

Já notei o PR, devo revisar até o fim da semana.

[EddieSCJ]

@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?

[EddieSCJ]

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

[PatrickOtero]

@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?

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.

[PatrickOtero]

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

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.

[EddieSCJ]

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

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.

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

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.