@typescript-eslint can't parse TypeScript 5.x tsconfig.json file format when using PNPM #7499
Comments
|
This was noted in #6380 and just never acted on because nobody's asked for it yet. I'm honestly surprised it took this long for someone to file an issue post-5.0 😄. Accepting PRs! |
|
I don't think that we manually parse tsconfigs - we pass them through to TS for parsing (which is why the 5.0 notes don't mention anything for us to do). I'm surprised that this errors. Part of me thinks there might be a version mismatch. @matthew-dean can you provide an isolated repro repo showing the error? |
|
Just chiming in to say that I use tsconfig |
Solution (TL;DR)PNPM users need to add this to their ExplanationOkay, this was very difficult to track down, and I have not been able to replicate it, because it has to do with the way that PNPM resolves peer dependencies. PNPM reasons that peer dependencies are related to the package that lists them as peers. And for whatever reason, in their great wisdom, the PNPM decided that, by default, peers that are do not match are auto-installed. You are right that PNPM reasons that if PNPM's logic is not entirely without reasoning. If peer dependencies are not installed automatically, there's a good chance of failures at runtime, since the package that needs that peer is expecting that specific major version range, and that package would be un-tested with other ranges. So, for all intents and purposes, in PNPM land, we can consider Anyway, you could call it a PNPM bug, except PNPM insists it's correct behavior. You could ask people to not use PNPM, but it's pretty popular these days because of its speed. So, I guess the above solution is best? If you know the TypeScript version you want to use with this package, then you must "force" it via the |
array|
We can probably close this since there is a workaround. Maybe worth documenting though? |
|
Here's a comment I left on the PNPM issue:
|
|
Oh wait, so I noticed that |
|
A long time ago in a galaxy far, far away the first version of our tool was built with Some time after that the ecosystem started to build tooling on top of our tooling (eg create-react-app). The problem was that at the time we specified a peer dependency range of Our solution was to just remove the peer dependency specification. We already had runtime validation of the version and the entire system would break without it - so it was essentially superfluous. Some time after that yarn2 introduced a feature that would enforce that packages do not access any other package unless it was explicitly declared as a dependency. We, of course, failed this assertion and people could not use our tooling under new yarn. The workaround was for us to add this config to our packages which would tell package managers we did actually depend on TS but it was okay if it didn't exist. typescript-eslint/packages/eslint-plugin/package.json Lines 97 to 101 in 4f34d0b This satisfied the constraints and made the ecosystem work and everyone was happy: users didn't get any warning logs on any version of any package manager because we didn't have That's the history of why we do what we do and it's setup in this exact manner. It's been working for a good number of years - so if it's breaking now then that's a regression in pnpm that will need to be solved in some way or another. |
|
@bradzacher Oh don't get me wrong, I 100% concur this is an PNPM problem, and they have lots of weirdness around resolving peer dependencies in ways that you don't expect. But I wanted to document all that stuff in the off-chance someone came across this exact situation with a solution that should work for a PNPM setup. But feel free to close as not applicable here. I don't actually think there's anything you can do on your end in terms of |
|
Sorry I was just dumping the entire history here as well so you can share it with the pnpm maintainer if needs be :) I'm not saying we're infallible here btw - our setup unique and unconventional, even if it has its reasons for existing! There might be something we can do to fix things - we're completely open to making changes as long as we don't cause logs for the CRA case or restrict users from new TS releases. Last time we made a change it was the yarn lead maintainer telling us exactly how to fix things - so we would likely want a similarly knowledgeable individual to advise again :) |
|
This statement is not correct:
pnpm will resolve a peer dependency using any package that is found in the dependencies of a direct or indirect parent package. It doesn't matter if the found package doesn't match the range in the Also, |
|
If zoltan says it works then I'm inclined to believe that :) it's probably local setup problems for users like outdated versions or something? Either way I don't think there's anything we should action in our project - so closing this off. |
|
In any case, if you can create a sample repository that reproduces the issue, feel free to create a new issue in the pnpm repository and we'll look into it. |
|
@zkochan Oh okay, so you're suggesting I was dealing with a PNPM bug of some kind, and this should have worked but didn't? |
|
That is a possibility. If you can submit an issue with steps to repro someone can check. |
Uh oh!
There was an error while loading. Please reload this page.
Before You File a Bug Report Please Confirm You Have Done The Following...
Relevant Package
parser
Playground Link
No response
Repro Code
ESLint Config
module.exports = {
parser: '@typescript-eslint/parser',
extends: ['eslint:recommended', 'plugin:@typescript-eslint/recommended'],
}
ESLint Config
No response
tsconfig
{ "extends": ["tsconfig.json"] "compilerOptions": { // ... } }Expected Result
Since microsoft/TypeScript#29118, ESLint should also be able to parse it and run normally.
Actual Result
Parsing error: Compiler option 'extends' requires a value of type string
Additional Info
This is a dupe of #6219, but it was closed without investigation, and it cannot be commented on. I also had to check
I have [searched for related issues](https://github.com/typescript-eslint/typescript-eslint/issues?q=is%3Aissue+label%3Abug) and found none that matched my issue.because otherwise you can't submit an issue.Work publicly started on this on or around January 20, 2021. This was announced as implemented in January 2023 and released on March 16, 2023.
Versions
@typescript-eslint/eslint-plugin6.4.0@typescript-eslint/parser6.4.0TypeScript5.0.3ESLint8.47.0node16.19.0The text was updated successfully, but these errors were encountered: