refactor: Fix autogenerate TS types

[dplewis]

Pull Request

• Report security issues confidentially.
• Any contribution is under this license.
• Link this pull request to an issue.

Issue

Currently developers would have to generate types themselves before committing. This could lead to types being missing in the future. I know there was talks for removing husky #2251 and there maybe a better way to do this. I'm open to discussion.

Approach

• Improve type build speed by removing prettier and lint formatting
• Regenerate all types
• Generate types per commit.

Tasks

• Add tests
• Add changes to documentation (guides, repository pages, code comments)

[parse-github-assistant]

Thanks for opening this pull request!

• ❌ Please link an issue that describes the reason for this pull request, otherwise your pull request will be closed. Make sure to write it as Closes: #123 in the PR description, so I can recognize it.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 100.00%. Comparing base (a929019) to head (7706a23).

Additional details and impacted files

@@            Coverage Diff            @@
##             alpha     #2460   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files           64        64           
  Lines         6256      6256           
  Branches      1451      1476   +25     
=========================================
  Hits          6256      6256           

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

[mtrezza]

Doesn't this cause quite a delay when building the types on every commit? I mean if a developer commits every few lines, that would trigger type rebuilding every time.

[dplewis]

That is correct. It's about 3-5 seconds.

[mtrezza]

And that delay may depend on the machine one is working on and be even slower in some cases. Not a fan of pre-commit hooks for code generation or modification - for many reasons. I believe a failing CI test and a good description in the error message makes more sense. Let's take the Parse Server options definitions for example. Generating them automatically would be a bad idea, because if someone edits a generated file instead of the source file for definitions, that change is lost and may go unnoticed. Better just fail. As for reviewing; mostly just requires pointing to the failing CI job and the contributor should know themselves what to do - with a good error msg. We should really get rid of husky.

[dplewis]

mostly just requires pointing to the failing CI job and the contributor should know themselves what to do - with a good error msg.

Let's do this. In this case removing build:types from the CI should let us know that a type is missing if the contributor writes a test case. We will have to ensure a test is written everytime a type has changed.

[dplewis]

Closing in favor of #2462