Open achingbrain opened 3 years ago
Please include a setup that reproduces the problem.
I think I've figured out what's happening.
The shared config is in the aegir module under src/config/tsconfig.aegir.json.
It's specified in extending tsconfig.json
files as:
{
"extends": "aegir/src/config/tsconfig.aegir.json", <-- does not work
// .. other stuff
}
Or alternatively:
{
"extends": "./node_modules/aegir/src/config/tsconfig.aegir.json", <-- works
// .. other stuff
}
Aegir uses typesVersions
in it's package.json
to direct tsc
to the ./dist
folder where the generated types are published:
"typesVersions": {
"*": {
"utils/*": [
"dist/utils/*"
],
"src/*": [
"dist/src/*",
"dist/src/*/index"
],
"src/": [
"dist/src/index"
]
}
}
The tsconfig file is not copied to dist
during building but it looks like tsc
is using the typesVersions
field to override where it loads the config file from.
If I copy the config file into dist/src/config
or if I modify the typesVersions
field as below it starts to work:
"typesVersions": {
// .. other fields
"src/config/tsconfig.aegir.json": [
"src/config/tsconfig.aegir.json"
]
}
Which I guess is fair enough, I can see why you might want different config files for different ts versions, though the docs only mention loading .d.ts
files from locations specified in typesVersions
.
The interaction here wasn't really intentional to be honest, but in retrospect is needed -- compiler options in tsconfig doesn't allow extra properties, so if you used a setting from a newer version of TS you'd have to set up typesVersions. We should add this to the docs, somewhere.
Ok, feel free to close this issue if it's not useful keeping open, my problem is resolved.
Bug Report
The docs say (emphasis mine):
This worked up until recently but is currently broken. I can't pin down a specific version where it stopped working as I guess the code that loads the config may be from a dependency of typescript that is shared across different versions.
We've got a module that contains org-wide tsconfig that we want our projects to extend - they could be regular modules, monorepo packages, etc.
Those projects can and do get pulled in as github urls (or https://gitpkg.now.sh/ urls for monorepo packages) for other modules as dependencies during PRs. Those projects are typically written in js but generate types from jsdoc comments using the npm
prepare
script for the current module to use, which now fails as it can't resolve theextends
path.You can't always predict which
node_modules
folder will contain the relevant dependency, so doing Node.js style resolution (e.g. stepping up through directories) is essential for our use-case.๐ Search Terms
๐ Version & Regression Information
Not sure, it was working before Christmas, now it does not.
๐ Actual behavior
Typescript does not resolve the
extends
path using Node.js style resolution.๐ Expected behavior
Typescript should resolve the
extends
path using Node.js style resolution.References:
https://github.com/microsoft/TypeScript/issues/18865 https://github.com/microsoft/TypeScript/issues/30701