-
-
Notifications
You must be signed in to change notification settings - Fork 14
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
parse
function resolves "extends": ".."
incorrectly
#149
Comments
obvious workaround: use |
fortunately this is used rarely, less than 200 json files on github with this value https://github.com/search?q=%2F%22extends%22%5Cs*%3A%5Cs*%22%5C.%5C.%22%2F+path%3A*.json&type=code&p=5 and not all of them with parents that have tsconfig.json and package.json. Is there any documentation in typescript on priority with ambiguous references? They have some obscure rules, this issue reminded me of evanw/esbuild#3247 also... so what would happen if the package.json also had a tsconfig field? can't wait until they decide to move to flat config like eslint... |
I don't know if there are. Apparently, tsconfig field has a higher priority. |
I had a look at typescripts implementation and it feels a bit like this works on accident rather than on purpose. For relative paths (starting with ./ or ../) they check the file system directly, only because they omitted the literal Which means it would fail if you had Is there a specific reason you are using |
It doesn't really help that the reference for tsconfig extends only mentiones "it may use node style resolution" https://www.typescriptlang.org/tsconfig#extends but does not go into detail how extensions or the whole filename can be omitted, or how it also appears to work if a package has a |
|
to make tsconfck extends resolve work exactly like typescripts, it would have to copy the whole code they use, which is a lot (follow the link i provided above). To stay fast and lean, i think it is ok to not implement edge cases that are rarely used/undocumented. That being said, the current resolve extends implementation favors node resolve over fs paths which can be expensive (createRequire), so doing fs checks first can be added with a reasonable amount of code. So in tsconfck/packages/tsconfck/src/parse.js Line 209 in ecd5d37
it could check for an fs path and then skip createRequire entirely. At that point a special case handling for |
NOTE: This is a fix to an edge case of some third party tools don't honor . as a valid path. See dominikg/tsconfck#149
Description
When the tsconfig.json has
"extends": ".."
and that pointed directory containspackage.json
.parse
function resolves that to the main field. But TypeScript andparseNative
function resolves that to../tsconfig.json
.Reproduction
https://stackblitz.com/edit/node-k9hb7p?file=index.js
Running
tsc -p foo --showConfig
returns the resolved config by TypeScript.Additional Information
Output of
npx envinfo --system --binaries --browsers --npmPackages tsconfck
(Note: the command in the template (npx envinfo --system --binaries --browsers --npmPackages "{tsconfck}"
) didn't include the tsconfck version number)The text was updated successfully, but these errors were encountered: