ci: Adding TypeScript build test

[wellwelwel]

In this PR:

1. In package.json, add the script test:tsc-build, allowing local testing before committing new PRs:

   •  npm run test:tsc-build

2. In .github/workflows/ci-tsc-build.yml, runs the command npm run test:tsc-build when new PRs are submitted

   • ✅ Successfully, it will exit with code 0
   • ❌ In case the tsc build command fails, it will print the build errors and exit with code 1
   • I reproduced the pattern from .github/workflows/ci-linux.yml
   • I didn't understand the main branch instead master, but I kept by default like all the other CI patterns 🥷🏻

3. In test/tsc-build/index.ts, only imports the mysql, mysql/promise and export them

   • It allows this CI to not need to be updated because of any future changes within them

4. In test/tsc-build/tsconfig.json, reproduces the almost options from original tsconfig.json, but:

   • Doesn't emit output files
   • Set skipLibCheck to false

---

Important

• This CI has a single purpose which is to test the TypeScript build like an external module
  • It will prevent future typings incompatibilities before PRs are merged
• The build test will not change any file

---

Tests

• To test it locally, I just ran the command npm run test:tsc-build
• To test the CI, I cloned (not forked) the master to a private repository and played between valid and invalids PRs 🥷🏻
• After concluding all the tests, I performed the fork

[sidorares]

Thanks for the PR ( and great description, as usual )

Question: is there any benefit having it in a completely separate workflow? We could have it in ci-linux, just as an extra step ( perhaps before main unit tests )

[wellwelwel]

@sidorares Note that in this own PR checks, the CI - TypeScript Build / Node.js 18.x (pull_request) has already tested 🤹🏻‍♀️

[sidorares]

Yeah, thats one of the benefits ( better visibility, as its displayed in a top level list of checks ). Also runs in parallel

[wellwelwel]

Thanks for the PR ( and great description, as usual )

Question: is there any benefit having it in a completely separate workflow? We could have it in ci-linux, just as an extra step ( perhaps before main unit tests )

I like to separate each responsibility in their respective files.
Would you like to change it?

[sidorares]

nah, I'm fine with that. In my head it probably sits closer to unit tests but I'll probably more productive knowing immediately when its a type failure