Skip to content
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

"@typescript-eslint/eslint-plugin" and "@typescript-eslint/parser" fail to resolve with yarn versions >= 3.0.0 #5175

Closed
NickLediet opened this issue Oct 3, 2024 · 4 comments

Comments

@NickLediet
Copy link

I was following the "Running the demo" section of the contribution page in the wiki and came across the following error when running yarn to install the dependencies:

➤ YN0001: │ Error: @typescript-eslint/eslint-plugin@^6.2.00 isn't supported by any available resolver

I noticed the extra 0 on the end of the semver and figured that was the culprit. It also appeared that @typescript-eslint/parser also had an extra 0 on the end of the semver.

I retried running yarn at version 1.22.22 like the CI and it resolved the dependencies without any issues.
I tested various major and minor releases of yarn and it appears the issue is replicated on all versions >= 3.0.0.

I wanted to confirm that the additional 0 at the end of the semver was not intentional before opening a PR to address it.

Details

  • Browser and browser version: N/A
  • OS version: macos sequoia 15.0
  • xterm.js version: 5.5.0
  • Yarn Version: 3.0.0 or greater

Steps to reproduce

  1. Install yarn 3.0.0 or greater (or use a version manager for this, I'm using volta
  2. Reset yarn cache with yarn cache clean
  3. Remove node modules rm -rf node_modules
  4. Install and resolve fresh deps with yarn (or volta run --yarn 3.0.0 yarn)
@jerch
Copy link
Member

jerch commented Oct 3, 2024

@NickLediet I'd say those are typos, which entered the stage in this PR #4612 (commit: 859c9ec)

Interesting, that yarn on an older version would let this pass, as far as I understand semver rules, leading zero should not be allowed to not mess up version sorting. My guess is, that the newer yarn package fixed that, while we did not spot the typo due to still being on older yarn.

@Tyriar
Copy link
Member

Tyriar commented Dec 12, 2024

We have only ever supported yarn v1. As I understand it yarn v2 changed things dramatically and yarn v3 reverted a lot of those changes? Regardless I think we should move back to npm at this point

duplicate of #5245

@Tyriar Tyriar closed this as completed Dec 12, 2024
@arcanis
Copy link
Contributor

arcanis commented Jan 16, 2025

I don't mind either way, but in the event someone would find the issue and get the wrong impression -

As I understand it yarn v2 changed things dramatically

No, we didn't (or at least not the way you mean 😄). Modern releases of Yarn are far more stable than 1.x ever was, and you have the choice between installing your project using node_modules, pnpm-style symlinks, or PnP install-less.

Performance-wise Yarn is still consistently faster than npm, and generally on par with pnpm.

and yarn v3 reverted a lot of those changes?

We didn't either. The only "revert" we did (in v4, I believe) was to make the cache global by default rather than local, as it's what most projects would expect. But it was a fairly small change, just a matter of removing a little bit of friction - it has always been possible to configure Yarn far more than npm ever allowed.

@Tyriar
Copy link
Member

Tyriar commented Jan 16, 2025

@arcanis thanks for clarifying the history, I might have some of it wrong as I'm mostly just spouting from memory what I've read, not experienced. I remember people complaining about yarn v2 introducing incompatibilities so it wasn't just a straight upgrade. That scared me off ever trying to upgrade tbh.

For us it's more about yarn adds unnecessary complexity that npm handles just fine (more dependencies for devs to install, configure in CI, etc.). We're not using any special features and while yarn might be faster, modern npm which comes with node is definitely fast enough. Same reason I wouldn't want us to use pnpm either.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants