Skip to content
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

[#IP-324] Change fp-ts version to 2.x and removed old italia-commons uses #154

Merged
merged 8 commits into from
Sep 9, 2021

Conversation

gquadrati
Copy link
Contributor

@gquadrati gquadrati commented Sep 3, 2021

List of Changes

  • upgrade fp-ts
  • upgrade io-ts
  • upgrade @pagopa/io-function-commons
  • upgrade express and @types/express
  • upgrade @pagopa/openapi-codegen-ts
  • refactor all code to handle new fp-ts constructs
  • refactor tests
  • healthcheck now uses semigroups to collect all errors and not just the first one

Motivation and Context

Migrate to fp-ts v2

How Has This Been Tested?

alredy present unit tests

Screenshots (if appropriate):

Types of changes

  • Chore (nothing changes by a user perspective)
  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to not work as expected)

Checklist:

  • My change requires a change to the documentation.
  • I have updated the documentation accordingly.

@gquadrati gquadrati force-pushed the IP-324--migrate-fp-ts branch from b1eb10d to 30c405b Compare September 3, 2021 15:02
@gquadrati gquadrati marked this pull request as ready for review September 3, 2021 15:08
@gquadrati gquadrati changed the title [IP-324] Change fp-ts versione to 2.x and removed old italia-commons uses [IP-324] Change fp-ts version to 2.x and removed old italia-commons uses Sep 3, 2021
@gquadrati gquadrati changed the title [IP-324] Change fp-ts version to 2.x and removed old italia-commons uses [#IP-324] Change fp-ts version to 2.x and removed old italia-commons uses Sep 6, 2021
@gquadrati gquadrati force-pushed the IP-324--migrate-fp-ts branch from 55c3b6c to ce0587e Compare September 6, 2021 13:17
@pagopa-github-bot
Copy link
Contributor

pagopa-github-bot commented Sep 6, 2021

Warnings
⚠️ This PR changes a total of 2814 LOCs, that is more than a reasonable size of 250. Consider splitting the pull request into smaller ones.
⚠️ Please include a Pivotal story at the beginning of the PR title (see below).

@pagopa/danger-custom-rules

Author: Federico Feroldi

Description: Shared rules for DangerJS, used in the Digital Citizenship projects

Homepage: https://github.com/pagopa/danger-plugin-digitalcitizenship#readme

Created7 months ago
Last Updated7 months ago
LicenseMIT
Maintainers5
Releases2
Direct Dependenciesauto-changelog, danger-plugin-yarn and pivotaljs
README

Custom DangerJS rules plugin

Custom rules over Danger CI automation.

Features

  • Cross-link with PivotalTracker stories, based on PR title
  • Warn when a PR has no description
  • Perform sanity checks on yarn.lock
  • Warn if npm-related files are added (as we use yarn)

@pagopa/express-azure-functions

Author: https://pagopa.gov.it

Description: Express adapter for Azure Functions

Homepage: https://github.com/pagopa/io-functions-express#readme

Created7 months ago
Last Updated7 months ago
LicenseMIT
Maintainers5
Releases1
Direct Dependencies
README

io-functions-express

Express adapter for Azure Functions.

Mostly a porting to TypeScript from azure-function-express.

New dependencies added: @pagopa/express-azure-functions and @pagopa/danger-custom-rules.

Example of PR titles that include pivotal stories:

  • single story: [#123456] my PR title
  • multiple stories: [#123456,#123457,#123458] my PR title

Generated by 🚫 dangerJS against e9611ff

@pagopa pagopa deleted a comment from pagopa-github-bot Sep 6, 2021
CreateMessage/handler.ts Outdated Show resolved Hide resolved
CreateNotificationActivity/handler.ts Outdated Show resolved Hide resolved
taskEither
.of<ServicePreferenceError, ServicesPreferencesMode>(
pipe(
TE.of<ServicePreferenceError, ServicesPreferencesMode>(
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we need to write explicit types here?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unfortunately in this cases TS cannot infer the Left type (since it's not defined), so we need to explicit it

@balanza
Copy link
Contributor

balanza commented Sep 7, 2021

/azp run

@azure-pipelines
Copy link

No pipelines are associated with this pull request.

WebhookNotificationActivity/handler.ts Outdated Show resolved Hide resolved
utils/healthcheck.ts Outdated Show resolved Hide resolved
utils/profile.ts Outdated Show resolved Hide resolved
utils/profile.ts Outdated Show resolved Hide resolved
utils/profile.ts Outdated Show resolved Hide resolved
utils/profile.ts Outdated Show resolved Hide resolved
utils/profile.ts Outdated Show resolved Hide resolved
@AleDore
Copy link
Contributor

AleDore commented Sep 7, 2021

Out of the scope of this PR, we must fix node version in .node-version and .nvmrc to 14.16.0

Comment on lines +415 to +449
return pipe(
// check whether the client can create a message for the recipient
TE.fromEither(
canWriteMessage(auth.groups, authorizedRecipients, fiscalCode)
),
// Verify if the Service has the required quality to sent message
TE.chain(_ =>
disableIncompleteServices &&
!incompleteServiceWhitelist.includes(serviceId) &&
!authorizedRecipients.has(fiscalCode)
? TE.fromEither(
pipe(
ValidService.decode(userAttributes.service),
E.bimap(
_1 => ResponseErrorForbiddenNotAuthorizedForRecipient,
_1 => true
)
)
: fromEither(right(true))
)
.chain(_ =>
// check whether the client can provide default addresses
fromEither(canDefaultAddresses(messagePayload))
)
.chain(_ =>
// check whether the client can ask for payment
fromEither(
canPaymentAmount(
messagePayload.content,
service.maxAllowedPaymentAmount
)
: TE.right(true)
),
TE.chainW(_ =>
// check whether the client can provide default addresses
TE.fromEither(canDefaultAddresses(messagePayload))
),
TE.chainW(_ =>
// check whether the client can ask for payment
TE.fromEither(
canPaymentAmount(
messagePayload.content,
service.maxAllowedPaymentAmount
)
)
.chain(_ =>
// create a Message document in the database
createMessageDocument(
messageId,
messageModel,
auth.userId,
fiscalCode,
messagePayload.time_to_live,
serviceId
)
),
TE.chainW(_ =>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What do you think if we use only one TE.fromEither

pipe(
      // check whether the client can create a message for the recipient
      canWriteMessage(auth.groups, authorizedRecipients, fiscalCode),
      // Verify if the Service has the required quality to sent message
      E.chain(_ =>
        disableIncompleteServices &&
        !incompleteServiceWhitelist.includes(serviceId) &&
        !authorizedRecipients.has(fiscalCode)
          ? pipe(
              ValidService.decode(userAttributes.service),
              E.bimap(
                _1 => ResponseErrorForbiddenNotAuthorizedForRecipient,
                _1 => true
              )
            )
          : E.right(true)
      ),
      E.chainW(_ =>
        // check whether the client can provide default addresses
        canDefaultAddresses(messagePayload)
      ),
      E.chainW(_ =>
        // check whether the client can ask for payment
        canPaymentAmount(
          messagePayload.content,
          service.maxAllowedPaymentAmount
        )
      ),
      TE.fromEither,
      TE.chainW(_ =>

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This way we are making that step synchronous, right?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You are right, all the steps before TE.taskEither will be executed on the pipe creation and not when the TaskEither is executed. IMHO is not a problem if the pipe is used inside the execution context. Do you think this pattern could generate unwanted behaviors?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The only one I see is not taking full advantages of node event loop

@gquadrati
Copy link
Contributor Author

Out of the scope of this PR, we must fix node version in .node-version and .nvmrc to 14.16.0

Yes, I've found it set to a higher values, so I thought it was ok

Copy link
Contributor

@BurnedMarshal BurnedMarshal left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM apart a few stylistic comments. Thanks @gquadrati for the amazing job.

GetMessage/handler.ts Show resolved Hide resolved
WebhookNotificationActivity/__tests__/handler.test.ts Outdated Show resolved Hide resolved
utils/healthcheck.ts Outdated Show resolved Hide resolved
@gquadrati gquadrati merged commit 63a18d4 into master Sep 9, 2021
@gquadrati gquadrati deleted the IP-324--migrate-fp-ts branch September 9, 2021 14:05
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants