fix(typescript): Support custom path in build mode #186
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Context
This PR is a small patch to the behavior when both
buildMode
andtsConfigPath
options are used together.This patch is a workaround for a larger use-case.
Use case
vite
), enable static typechecking w/o emitting any output.vite build
), emit.This is possible today with
buildMode
.The gap is when specifically when building a library. In this scenario, vite compiles the typescript but another tool is needed to emit the declaration files. This is because vite does not generate declaration files for you.
vite-plugin-checker
internally controls the--noEmit
flag based on whetherbuildMode
is true or false. As a result, mytsconfig.json
cannot have:...or else, you get an error from TypeScript that looks something like:
Ideally,
vite-plugin-checker
would expose more granular control over the arguments. For example, it would be nice to be able to directly specify tsConfig that takes precedence over tsconfig.json. Something like:This would extend the plugin-specific config on top of tsconfig.json to be able to have control over ts behavior specifically based on build vs dev. I have seen this as a common approach in other popular libraries.
I understand that this may be more challenging to pull off, and conflicts with some of the other plugin-level behaviors (e.g. what do we do if
noEmit
is provided intsConfig
?). It also takes more thought w.r.t. the longer term implications.This PR does not attempt to tackle that effort or address these harder questions. Instead, it works around it by using a different tsconfig.json when in build mode. For example:
tsconfig.json:
vite.config.js:
This PR would also address #181