add eslint rules and plugins for "Apply Linting Only to Files Updated in git #1270"

[Shubh152]

What kind of change does this PR introduce?

feature

Issue Number:

Fixes #1270

Did you add tests for your changes?

Snapshots/Videos:

If relevant, did you update the documentation?

Summary
added eslint rules and plugins as requested in ISSUE#1270 and PR#1353

Does this PR introduce a breaking change?

Other information

Have you read the contributing guide?

Yes

[github-actions]

Our Pull Request Approval Process

We have these basic policies to make the approval process smoother for our volunteer team.

Testing Your Code

Please make sure your code passes all tests. Our test code coverage system will fail if these conditions occur:

1. The overall code coverage drops below the target threshold of the repository
2. Any file in the pull request has code coverage levels below the repository threshold
3. Merge conflicts

The process helps maintain the overall reliability of the code base and is a prerequisite for getting your PR approved. Assigned reviewers regularly review the PR queue and tend to focus on PRs that are passing.

Reviewers

When your PR has been assigned reviewers contact them to get your code reviewed and approved via:

1. comments in this PR or
2. our slack channel

Reviewing Your Code

Your reviewer(s) will have the following roles:

1. arbitrators of future discussions with other contributors about the validity of your changes
2. point of contact for evaluating the validity of your work
3. person who verifies matching issues by others that should be closed.
4. person who gives general guidance in fixing your tests

CONTRIBUTING.md

Read our CONTRIBUTING.md file. Most importantly:

1. PRs with issues not assigned to you will be closed by the reviewer
2. Fix the first comment in the PR so that each issue listed automatically closes

Other

1. 🎯 Please be considerate of our volunteers' time. Contacting the person who assigned the reviewers is not advised unless they ask for your input. Do not @ the person who did the assignment otherwise.
2. Read the CONTRIBUTING.md file make

[palisadoes]

Are the linting errors expected for only this PR and will work satisfactorily from the CLI?

[Shubh152]

No. These errors are due to the new rules added and will be there even for the CLI

[palisadoes]

No. These errors are due to the new rules added and will be there even for the CLI

That is not the goal as stated in the issue. We only want linting to be done against files committed in git. Now the next person submitting a PR will have to fix hundreds of linting errors for the remaining tests to pass.

Please contact the author of this PR for assistance

• Lint only updated files with stricter linting talawa-api#1635

DO NOT CLOSE THIS PR.

Make any adjustments to your branch and do the follow up in this PR

[Shubh152]

The linting errors are due to the old scripts in the PR workflow. These scripts probably check linting for the whole of the repository and the errors arise due to new linting errors added. We will have to update the PR workflow to check for linting in committed files.
The changes I made will check staged files before linting in the CLI, not in the PR workflow. If you want I can try to change the PR workflow. Please guide @palisadoes .

[palisadoes]

Please make the changes so that it works as expected
The PR workflow scripts were supposed to cycle through each file submitted on the PR

You may have repurposed the script names so they are not failing

You'll need to restore the functionality, possibly with a new script name

[Shubh152]

From what I can see in the PR workflows, the linting is performed for the whole repo and not only files submitted in the PR. Do you want me to change the PR workflow to check only submitted files? @palisadoes

[Shubh152]

The errors we see are due to new rules like tsdoc/syntax, import/no-duplicates, and @typescript-eslint/no-explicit-any which were not fixed in old files. Its better we fix them somehow like advised in the PR you mentioned or remove these rules. Please advice @palisadoes

[palisadoes]

1. I know it will be a lot of work, but we need to fix them, preferably in this PR because that was the goal
2. Can you facilitate that? Or is there a better approach that will guarantee this will be completed faster?

[EshaanAgg]

@palisadoes We should revert the rules and open a new PR for each rule. It must be ensured that whenever any change to linting and formatting configurations are made, they must be added to the codebase completely in that PR itself. Bloating this PR with eslint changes is not wise IMO as then we are delaying this PR when it is ready. Also it would allow us to test these changes concerned with staged-lint in isolation.

[Shubh152]

@palisadoes
The majority of errors are due to "no-explicit-any".

1. One easy approach is to convert all "any" types we have encountered until now to "unknown" type using an inbuilt auto-fixer in eslint, We will be able to do it much faster without compromising much on the type safety as "unknown" is more typesafe than "any". After that, we can turn this auto-fixer off for future type-safety. I can do it if you want.

2. Otherwise we will have to change each file separately maybe directory-wise, which will be tedious but ensure more type safety.

Error due to rules other than "no-explicit-any" can be fixed by hand as they are not much in number. I can assist you with that.

[EshaanAgg]

@Shubh152 As a middle ground, we can do the following

• Fix the errors due to the other rules in this PR, expect no-explicit-any
• Turn the rule no-explicit-any off and open a new PR. I am advising the same as while using unknown is safer than any, it would still require the use of type guards to narrow the types safely, and that would make this PR longer and harder to review. I also believe if we are going to put in manhours into this job, we might as well do it with stricter types, and using unknown also when we actually can't be sure about the types of the values returned.

[Shubh152]

I agree with you @EshaanAgg . I'll be happy to help with that. I will do as you advice and then open another PR for the planned changes .Should we @palisadoes ?

[palisadoes]

I agree with you @EshaanAgg . I'll be happy to help with that. I will do as you advice and then open another PR for the planned changes .Should we @palisadoes ?

Yes. this is long overdue.

[palisadoes]

Would it be easier to split this up into multiple issues each handling a different linting rule? That way we could split up the workload.

[Shubh152]

Would it be easier to split this up into multiple issues each handling a different linting rule? That way we could split up the workload.

There is only one linting rule "no-explicit-any" which is a problem. Rest I will fix in this PR. I think file or directory-wise approach will be good.

[palisadoes]

@NamitBhutani Could this approach be used in your case?

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (e04e50a) 97.44% compared to head (09a6a9d) 97.35%.
Report is 8 commits behind head on develop.

Additional details and impacted files

@@             Coverage Diff             @@
##           develop    #1397      +/-   ##
===========================================
- Coverage    97.44%   97.35%   -0.09%     
===========================================
  Files          138      136       -2     
  Lines         3683     3560     -123     
  Branches      1076     1036      -40     
===========================================
- Hits          3589     3466     -123     
  Misses          89       89              
  Partials         5        5              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[NamitBhutani]

@NamitBhutani Could this approach be used in your case?

For the admin repo, there are a lot of other errors too, other than the ones related to "typescript-eslint/no-explicit-any". It is definitely possible to fix all but would require a lot of changes and reviews, especially for "@typescript-eslint/no-non-null-assertion".

[palisadoes]

@NamitBhutani Could this approach be used in your case?

For the admin repo, there are a lot of other errors too, other than the ones related to "typescript-eslint/no-explicit-any". It is definitely possible to fix all but would require a lot of changes and reviews, especially for "@typescript-eslint/no-non-null-assertion".

What about the approach of linting only the committed files and those submitted in the PR? That will assist greatly.

[palisadoes]

@Shubh152 This has been merged. Create another PR for the remaining linting errors and use the same original issue as a reference.