Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto
  • ¿Algo no está bien?
#8 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
3/5
Tiempo estimado
1-2 días
Aptitud para principiantes
72/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
javascript, node.js
Área
backend, cli

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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
Lenguaje dominante
JavaScript
Estrellas
0
Forks
0
Merge medio
55 min
PR fusionados (30 d)
12

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de modulane/dev-workspace-cli

Todos los issues de modulane/dev-workspace-cli

Issues similares

Más issues de JavaScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.