Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

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

Aperta
#8 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
3/5
Tempo stimato
1-2 giorni
Idoneità per principianti
72/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
javascript, node.js
Ambito
backend, cli

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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
Lingua principale
JavaScript
Stelle
0
Fork
0
Merge medio
7m
PR unite (30g)
6

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di modulane/dev-workspace-cli

Tutte le issue di modulane/dev-workspace-cli

Issue simili

Altre issue su JavaScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.