Allow user to specify a custom project (tsconfig path)

[keyz]

Related: #38

This PR adds a new project config for tshy to extend from. With this new option, you can have separate tsconfigs for typechecking (linting) and compilation, where tshy will only be using the compilation config. Let me know how you feel about this approach!

Why?

It's common to have multiple tsconfig files co-exist in a project, where:

• The default tsconfig.json contains "noEmit": true and "include": ["**/*.ts"]. This is used by typechecking and type-aware typescript-eslint; VSCode also picks up this file by default.
• A separate tsconfig.build.json for compilation, invoked via tsc -p tsconfig.build.json (or TypeScript project references in a monorepo).

Here's a real-world monorepo example:

• Leaf tsconfig.json (default), tsconfig.build.json, and type-aware eslint config
• Root tsconfig.build.json, tsconfig.typecheck.json, and the script to invoke compilation

[keyz]

here

[keyz]

Friendly bump @isaacs

[isaacs]

Sorry, been a busy holiday season, just getting back to it.

I think the only suggestion I have right now is it should maybe be called "project" to match the setting in ts-node and tsc? What do you think?

[keyz]

Sounds good to me! Gonna update the PR in a bit

[keyz]

cc @isaacs -- are you ok with this? The behavior is being tested via the integration test (basic-custom-project). Unclear whether there's a good way to test it at unit test level.

[isaacs]

This should be covered by the tests in test/tsconfig.ts

[isaacs]

This seems to work as intended, no major issues with the code. Does need a test, and the check against invalid settings could be better. You can update it or I can soon :)

[isaacs]

This should be covered by the tests in test/tsconfig.ts

[keyz]

Thanks @isaacs! I updated the file existence check, but I'm gonna defer the test/tsconfig.ts to you if that's ok -- think that might require a few changes to the test setup.