Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

Lifecycle hooks are hidden from the script list but never run in Yarn 2+ projects

Ouverte
  • Quelque chose ne va pas ?
#8 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Personne n'a encore pris cette issue.

Évaluation

Difficulté
3/5
Temps estimé
1-2 jours
Accessibilité débutants
72/100
Type d'issue
Bug
Clarté
Clairement spécifiée
Activité
Active
Stack technique
javascript, node.js
Domaine
backend, cli

Piste de recherche

Start with lib/workspace.js and lib/package-managers.js to trace script grouping and package manager detection, then follow their callers in cli.js. Read the existing script and detection tests, and run them before adding coverage for Yarn 2+ signals and hook execution. Done when Yarn 2+ lists hooks separately while Yarn 1 and other managers still group hooks, with the README updated.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

bug
Description

Since #4, the script list attaches pre/post hooks to their main script: build is shown with (+ prebuild, postbuild), and prebuild / postbuild are no longer listed. The README explains why:

Running build runs its hooks too, as the package manager normally does.

That is true for npm, pnpm, Bun and Yarn 1. Since version 2, Yarn no longer runs custom pre/post scripts, by design (Yarn migration guide). In a Yarn 2+ project, the CLI therefore:

  • announces hooks that don't run: build is described as (+ prebuild, postbuild), but only build runs;
  • hides scripts with no way to reach them: prebuild and postbuild are removed from the list, so they can't be run from the CLI at all.
Steps to reproduce

Requires Corepack to be enabled (corepack enable). On Node.js versions that don't bundle it, run npm install --global corepack first.

  1. Create a project inside a scratch workspace:

    mkdir -p /tmp/dws-repro/berry-hooks
cd /tmp/dws-repro/berry-hooks

  2. Add this package.json:

    {
  "name": "berry-hooks",
  "packageManager": "[email protected]",
  "scripts": {
    "prebuild": "echo prebuild ran",
    "build": "echo build ran",
    "postbuild": "echo postbuild ran"
  }
}

  3. Install, which creates yarn.lock, then start the published CLI. DEV_WORKSPACE_CONFIG keeps your own saved workspace untouched:

    yarn install
DEV_WORKSPACE_CONFIG=/tmp/dws-repro/config.json \
  npx -p @modulane/[email protected] dws --workspace /tmp/dws-repro

  4. Select berry-hooks, then build.

Actual behaviour
  Package manager: yarn (from the packageManager field)

? Select a script
❯ ▶  build
  ↩  Back to projects
echo build ran  (+ prebuild, postbuild)

  ----------------------------------------
  Running: yarn run build
  Directory: /tmp/dws-repro/berry-hooks
  ----------------------------------------

build ran
  Command completed successfully.

prebuild and postbuild neither run nor appear in the list. Both still work when run directly, for example with yarn run prebuild.

Expected behaviour

In a Yarn 2+ project, prebuild and postbuild appear as ordinary scripts, and build doesn't claim to run them.

Behaviour by package manager

Running <tool> run build on the same package.json:

Package manager Runs prebuild / postbuild
npm 10.9.7 Yes
pnpm 9 and 10 Yes
Bun 1.4.4 Yes
Yarn 1.22.22 Yes
Yarn 2.4.2, 3.8.7 and 4.18.1 No

Projects that follow Yarn's advice and chain hooks explicitly ("build": "yarn prebuild && …") are partly affected: the chained hooks run, but postbuild is still announced and still hidden.

Cause
  • groupLifecycleScripts() runs inside getScripts(), before the package manager is known, so hooks are always grouped.
  • detectPackageManager() reports yarn for both Yarn 1 and Yarn 2+.
  • CI doesn't catch it:
    • it installs Yarn 1 through npm install --global yarn;
    • the real-script test checks which tool ran a script, not whether hooks ran.
Suggested fix

  1. Tell Yarn 2+ apart from Yarn 1 during detection. Two signals hold for Yarn 2, 3 and 4:

    • a packageManager field set to yarn@2 or later;
    • a yarn.lock that contains a __metadata: block. Yarn 1 lockfiles never have one.

    A .yarnrc.yml file is not a reliable signal on its own: the reproduction above has none.

  2. Group hooks only when the detected tool runs them. For example, the grouping could move out of getScripts() to after detection in cli.js, or getScripts() could receive the package manager.

  3. Add tests:

    • detection of Yarn 2+ from both signals;
    • a real-script case that checks whether hooks ran, with a Yarn 2+ project in CI.

  4. Update the README paragraph to mention that Yarn 2+ lists these hooks separately.

I'd be glad to open a PR for this if the approach suits you.

Environment
  • @modulane/dev-workspace-cli 0.5.0, installed from npm. lib/ is identical on main at dfccb6b.
  • Node.js 22.22.2, Linux x64
  • Yarn 4.18.1 through Corepack 0.34.6, plus Yarn 2.4.2 and 3.8.7 for the comparison table
Langage dominant
JavaScript
Étoiles
0
Forks
0
Merge moyen
7 min
PR mergées (30 j)
6

Préparer son environnement

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 modulane/dev-workspace-cli

Toutes les issues de modulane/dev-workspace-cli

Issues similaires

Plus d'issues JavaScript

Recevez les nouvelles issues par e-mail

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