Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

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

Offen
  • Stimmt etwas nicht?
#8 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
3/5
Geschätzter Aufwand
1-2 Tage
Anfängerfreundlichkeit
72/100
Issue-Typ
Bug
Klarheit
Klar beschrieben
Aktivitätsstatus
Aktiv
Tech-Stack
javascript, node.js
Bereich
backend, cli

Rechercherichtung

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.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

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
Vorherrschende Sprache
JavaScript
Sterne
0
Forks
0
Ø Merge
7 Min.
Gemergte PRs (30 T.)
6

Entwicklungsumgebung

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus modulane/dev-workspace-cli

Alle Issues in modulane/dev-workspace-cli

Ähnliche Issues

Weitere Issues zu JavaScript

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.