[#1756] Add JSON validation and migrate api.js to TypeScript

[vvidday]

Fixes #1756
Should not be merged before #1905

Proposed commit message

Currently, the objects produced by reading from summary.json,
authorship.json and commits.json are not validated against any schema.
This results in these objects having an implicit any type, which might
lead to type errors during runtime.

Let's add support for JSON validation with the zod library and migrate
the file where the JSON files are parsed, api.js, to TypeScript. This
will increase type safety and enable the migration of other files.

Other information

Organization

The files containing types are in the src/types folder, with the following layout:

└── types/
    ├── zod/
    │   ├── authorship-type.ts
    │   ├── commits-type.ts
    │   └── summary-type.ts
    ├── types.ts
    └── window.ts

The files in the zod subdirectory are zod schemas that are used to validate the parsed objects from authorship.json, commits.json and summary.json, whereas the other two files contain regular typescript interfaces, hence the distinction. window.ts contains type definitions for all the global variables stored in the window object (window.XXX), and all the other 'normal' types are in types.ts. Please let me know if you have any suggestions for better organization!

api.ts

Changes to this file were mostly related to adding types/typecasts to make it work with the typescript compiler. The only functional change is the three xxxSchema.parse(json) under api.loadSummary, api.loadCommits and api.loadAuthorship. This change will make it so that if the object doesn't match the schema (which can be either due to a modified .json file or a change to the schema in the backend of any of the three .json files), the app will throw an error instead of passing on the data. This will make it so the error is surfaced immediately instead of being passed on to other components and silently breaking elsewhere.

The reason why I'm migrating the whole file in this PR is because adding JSON validation requires the migration of most of the file (everything in window.api), and the only 'extra' aspects are just the type definitions of the other global variables (window.XXX). If we want to separate this into 2 PRs, it will be a bit weird since we will be migrating half the file, and as far as I can tell there isn't an easy way to get typescript to ignore a section of the file (see microsoft/TypeScript#19573)

Changes to eslint

The plugin added in line 9 allows proper resolving of typescript file imports, the change of rule from line 51 onwards makes the linter allow us to import typescript files like import ... from ../file instead of import ... from ../file.ts (which throws an error). The side effect is that the typescript imports in the .vue files must also be changed to remove the .ts, which is why this PR also modifies vue files. Although, if it is better, I can temporarily ignore the rule here and open a separate PR to change this.

[ckcherry23]

Learned a lot from your code as I don't have much prior experience using TypeScript! Regarding file structuring, I think we could move the files user.ts and segment.ts from the utils directory to the types directory for better organization.

[sikai00]

The JSON validation addition looks good to me! Although, I am of the opinion that the changes to eslint should be in a separate PR following the good practice of limiting each PR to tackling a single issue

[vvidday]

Learned a lot from your code as I don't have much prior experience using TypeScript! Regarding file structuring, I think we could move the files user.ts and segment.ts from the utils directory to the types directory for better organization.

I agree, that would definitely help the organization/structure of the files! Since it will also require changing some .vue files due to imports, I think it will be better to do the move in a separate PR to limit the scope of this one.

[vvidday]

The JSON validation addition looks good to me! Although, I am of the opinion that the changes to eslint should be in a separate PR following the good practice of limiting each PR to tackling a single issue

Thanks, I'll open a separate PR for the eslint changes. For now, I added two lines in .eslintrc.json to ignore the import errors, to let CI continue with the cypress tests/deployments. I'll remove those lines once that PR is merged and I can merge the changes into this branch.

[zhoukerrr]

Really impressive work given how fast you did it. I like the organisation of the files that you added. Codes are also arranged in an easy-to-follow manner.

One small request will be to add the function parameter types wherever appropriate. That way when the functions are called, we can avoid any type error directly. Do let me know your thoughts as well.

[zhoukerrr]

Thanks for the work. LGTM!

[dcshzj]

@vvidday Sorry, there are some file conflicts in this branch. Are you able to resolve them?

[vvidday]

@dcshzj Sorry, have just resolved the conflicts!

[github-actions]

The following links are for previewing this pull request:

• Dashboard Preview: https://dashboard-1903-pr-reposense-reposense.surge.sh
• Docs Preview: https://docs-1903-pr-reposense-reposense.surge.sh