Yarn command gates use the launcher version instead of the version selected by yarnPath

Ouverte
  • Quelque chose ne va pas ?
#3,327 0 commentaires 0 réactions 1 personne assignée Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

@jong-kyung y travaille déjà.

Depuis le 3/11/2026.

  • #3329 par @voidzero-bot — fermée sans fusion

Évaluation

Cette issue n'a pas encore été évaluée.

Description

- P2: has workaround

Problem

Vite+ selects Yarn behavior from the version in packageManager, which is the launcher it downloads. However, the launcher hands the command to the release in yarnPath unless ignorePath or YARN_IGNORE_PATH disables that delegation. When the two versions differ, Vite+ makes its decision for a version that does not run the command.

The most serious result is a silent false success. With packageManager: "[email protected]" and yarnPath pointing to Yarn 3.8.7, vp unlink prints a warning and exits with code 0, but the portal: resolution stays in package.json. Running the same launcher directly removes it. This was found in the review of #3286.

Reproduction

These steps need the unlink gate from #3286.

  1. Set "packageManager": "[email protected]" in package.json.
  2. Copy bin/yarn.js from @yarnpkg/[email protected] to .yarn/releases/yarn-3.8.7.cjs.
  3. Create .yarnrc.yml with nodeLinker: node-modules and yarnPath: .yarn/releases/yarn-3.8.7.cjs.
  4. Run vp install.
  5. Create ../linked-lib/package.json with the name linked-lib, then run vp link ../linked-lib.
  6. Run vp unlink linked-lib.

Expected: Yarn 3 removes the linked-lib resolution from package.json.

Actual: Vite+ prints this warning and exits with code 0, and the resolution stays.

warn: yarn unlink requires Yarn Classic or yarn >= 3.0.0. Skipping.

Affected checks

Result of a mismatch Checks Launcher and effective version Source
Skips a supported command unlink, patch-commit --save (Yarn 3) 2.x and 3 or later #3286
Skips a supported command audit (Yarn 2.4) Below 2.4 and 2.4 or later #3286
Skips a supported command patch, patch-commit, rebuild, whoami Classic and Berry main
Skips a supported command list, licenses, team Berry and Classic main
Falls back to npm stage (Yarn 4.16) Below 4.16 and 4.16 or later main
Rejects a supported option not_supported(yarn ...) rules with version conditions Depends on the rule Mostly main
Builds arguments for the wrong Yarn family is_berry() branches Classic and Berry main
Sends a setting the effective Yarn rejects YARN_ENABLE_TIPS in resolve_for_manager 4.x and 2.x or 3.x main

This table comes from reading the code. Only the Yarn 2 launcher delegating to Yarn 3 has been reproduced end to end. The Classic and Berry rows, and whether the Classic launcher delegates in the same way, still need to be confirmed.

Possible direction

An earlier attempt in #3286 (eb4b2c713) ran yarn --version before every Yarn command. It is accurate because Yarn applies its own configuration rules, but it adds a process to every command.

A cheaper option is to resolve with the launcher version first and query the effective version only when Vite+ declines the request, which means a Noop, an InvalidArgument, or a FallbackCommand diagnostic. If the query reports a different version, Vite+ resolves again. Commands that run need no query because Yarn reports its own errors.

This option would not fix the is_berry() argument branches or YARN_ENABLE_TIPS, because those affect commands that do run. Reading the version from the yarnPath file name avoids a process, but the name can be arbitrary, and it would not account for parent or home configuration files or environment overrides.

Langage dominant
Rust
Étoiles
6.5k
Forks
297
Merge moyen
1 j 4 h
PR mergées (30 j)
238

Préparer son environnement

Ouvrir dans Codespaces

Lance le conteneur de développement du projet dans votre navigateur, avec votre propre compte GitHub.

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de voidzero-dev/vite-plus

Toutes les issues de voidzero-dev/vite-plus

Issues similaires

Plus d'issues Rust

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.