Hi team,
We have an edge case we’d like to discuss with you.
We're developing a CLI tool that is used by both external and internal contributors. By default, our library exposes only the types relevant for external contributors. However, for internal contributors, we want to expose additional types.
To achieve this, we provide an alternate set of types that internal contributors can opt into using the paths property in their tsconfig.json, like so:
{
"compilerOptions": {
"paths": {
"ourLibrary": ["./node_modules/ourLibrary/internal/build/index.d.ts"]
}
}
}
This setup works nicely for TypeScript, allowing internal consumers to get extended types.
However, it causes issues when used with vite-tsconfig-paths. The plugin assumes that paths entries always reference actual code, so it rewrites every import of ourLibrary to point to the .d.ts file. This leads to runtime failures, as the file contains types only—not executable code.
We’re open to contributing a fix, but we’d like to ask: would it be possible to fix this in version 5?
Version 6 is still in alpha, and we’d prefer a solution that works with the stable version.
Thanks!
Hi team,
We have an edge case we’d like to discuss with you.
We're developing a CLI tool that is used by both external and internal contributors. By default, our library exposes only the types relevant for external contributors. However, for internal contributors, we want to expose additional types.
To achieve this, we provide an alternate set of types that internal contributors can opt into using the
pathsproperty in theirtsconfig.json, like so:{ "compilerOptions": { "paths": { "ourLibrary": ["./node_modules/ourLibrary/internal/build/index.d.ts"] } } }This setup works nicely for TypeScript, allowing internal consumers to get extended types.
However, it causes issues when used with
vite-tsconfig-paths. The plugin assumes thatpathsentries always reference actual code, so it rewrites every import ofourLibraryto point to the.d.tsfile. This leads to runtime failures, as the file contains types only—not executable code.We’re open to contributing a fix, but we’d like to ask: would it be possible to fix this in version 5?
Version 6 is still in alpha, and we’d prefer a solution that works with the stable version.
Thanks!