仓库指标
- Star
- (48,455 star)
- PR 合并指标
- (平均合并 6天 17小时) (30 天内合并 9 个 PR)
描述
🔎 Search Terms
"showConfig", "paths", "extends", "relative"
🕗 Version & Regression Information
v5.2.2 (no regression AFAIK)
⏯ Playground Link
https://stackblitz.com/edit/stackblitz-starters-gst2kr?file=tsconfig.json
Commands:
-
npm run config->tsc --showConfig -
npm run trace->tsc --noEmit --traceResolutionUse this to confirm thatfoodoes resolve to./this-path-should-be-in-config/bar.ts
💻 Code
No response
🙁 Actual behavior
Given a tsconfig that extends another config:
./tsconfig.json
{
"extends": "./this-path-should-be-in-config/tsconfig.json"
}
./this-path-should-be-in-config/tsconfig.json
{
"compilerOptions": {
"paths": {
"foo": ["./bar"]
}
}
}
The resolved tsconfig (via tsc --showConfig) doesn't reflect that ./bar is actually resolved relative to ./this-path-should-be-in-config/tsconfig.json:
{
"compilerOptions": {
"paths": {
"foo": [
"./bar"
]
}
},
"files": [
"./file.ts"
]
}
🙂 Expected behavior
For the config to include the relevant information (e.g. the relative path):
{
"compilerOptions": {
"paths": {
"foo": [
"./this-path-should-be-in-config/bar"
]
}
},
"files": [
"./file.ts"
]
}
Currently, it seems to indicate that paths is resolved relative to the CWD. When it's in fact relative to this-path-should-be-in-config.
It's also impossible for a custom TypeScript paths resolver (e.g. https://github.com/privatenumber/get-tsconfig) to correctly resolve the paths aliases based on this output.