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

[DEVEX-101] Update @pagopa/eslint-config #4

Merged
merged 21 commits into from
May 27, 2024

Conversation

lucacavallaro
Copy link
Member

@lucacavallaro lucacavallaro commented Apr 15, 2024

List of changes

  1. add code-review.yaml pipeline
  2. configure yarn 4
  3. add @pagopa/eslint-config workspace that exports an eslint flat configuration

ESlint plugins configured

  • @eslint/js - default JS rules from eslint
  • typescript-eslint - strict and stylistic rules for TypeScript
  • eslint-plugin-vitest - common best practices for vitest
  • eslint-plugin-perfectionist - non-blocking, auto-fixable ordering rules (import, classes, objects)
  • eslint-plugin-prettier to avoid conflicts with prettier formatting

turbo.json Show resolved Hide resolved
@lucacavallaro lucacavallaro marked this pull request as ready for review April 16, 2024 08:59
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.

We should consider to extend the ruleset adding some plugin to enforce some concepts:

Some ruleset are not yet released for ESLint 9 like we should keep an eye on it:

@gunzip
Copy link
Contributor

gunzip commented Apr 24, 2024

What about having two sets? ie. lite vs nazi (we can settle on "lite" for this pr)

@BurnedMarshal
Copy link
Contributor

What about having two sets? ie. lite vs nazi (we can settle on "lite" for this pr)

I agree on having multiple base rulset, but some principles must be guarantees even in lite configuration.

@gunzip
Copy link
Contributor

gunzip commented Apr 24, 2024

I'd like to have only auto-fixable items in lite. Which principles are you referring to @BurnedMarshal ?

@BurnedMarshal
Copy link
Contributor

I'd like to have only auto-fixable items in lite. Which principles are you referring to @BurnedMarshal ?

Have only auto-fixable rules is impossible, because even the raccomended ts-eslint and raccomended eslint rules have rules that don't support autofix or have reported errors on autofix feature.
Some of the principles that I would like to see enforced are:

  • functional programming
  • immutability (reducing side effects)
  • complex functions obtained composing simple functions
  • reduce dangerous JS patterns

@gunzip
Copy link
Contributor

gunzip commented Apr 24, 2024

I've doubts about enforcing functional programming everywhere. Think about a frontend application or infrastructure layers (sdk) where it's not mandatory, neither strongly suggested, to adopt fp-ts or something alike.

@BurnedMarshal
Copy link
Contributor

I've doubts about enforcing functional programming everywhere. Think about a frontend application or infrastructure layers (sdk) where it's not mandatory, neither strongly suggested, to adopt fp-ts or something alike.

I agree, functional programming enforcing can be enabled on "nazy" ruleset or specific rule with functional paradigm.

@lucacavallaro
Copy link
Member Author

lucacavallaro commented Apr 25, 2024

I've doubts about enforcing functional programming everywhere. Think about a frontend application or infrastructure layers (sdk) where it's not mandatory, neither strongly suggested, to adopt fp-ts or something alike.

I agree, functional programming enforcing can be enabled on "nazy" ruleset or specific rule with functional paradigm.

I think that functional programming and immutability should be enforced at project-level, for specific workspace/folders.

With this common rules (that will be used by the whole PagoPA org) we should enforce writing good and modern TypeScript code.

Functional programming is not "nazi", it's just a different paradigm that can be used in some workspaces.

@lucacavallaro lucacavallaro requested a review from a team as a code owner May 2, 2024 09:51
@BurnedMarshal
Copy link
Contributor

I've doubts about enforcing functional programming everywhere. Think about a frontend application or infrastructure layers (sdk) where it's not mandatory, neither strongly suggested, to adopt fp-ts or something alike.

I agree, functional programming enforcing can be enabled on "nazy" ruleset or specific rule with functional paradigm.

I think that functional programming and immutability should be enforced at project-level, for specific workspace/folders.

With this common rules (that will be used by the whole PagoPA org) we should enforce writing good and modern TypeScript code.

Functional programming is not "nazi", it's just a different paradigm that can be used in some workspaces.

The functional paradigm is the suggested way for Azure Functions and App Service template in the dx-typescript monorepo, and will be provided as template. Do you mean that linter rules that enforce functional constraint must be defined inside the dx-typescript? I'll provide a ruleset specific in here anyway:

  • recommended
  • functional

Copy link
Contributor

@gunzip gunzip left a comment

Choose a reason for hiding this comment

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

do this requires more work?

@lucacavallaro lucacavallaro merged commit 8c68693 into main May 27, 2024
2 checks passed
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.

3 participants