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

[NickLediet]

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]

@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]

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 https://github.com/xtermjs/xterm.js/issues/5245

[arcanis]

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]

@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.