Node tooling install silently reports success after a failed npm install (version constraints are shell-escaped)

[UltraBob]

Summary

During install of drupal-code-quality (v1.0.6), the Phase 3 "JS toolchain dependencies" step fails to install the DCQ npm dev-dependencies, but the installer continues and reports the Node toolchain as successfully installed. A user who does not read the console output line-by-line is left without ESLint / Prettier / Stylelint / CSpell tooling while believing it is present.

There are two distinct problems. The more important one for reproducing the failure is Bug 1 (a version-compatibility issue), which is separate from the cosmetic shell-escaping in Bug 2.

Bug 1 — a pinned dependency version cannot be resolved

The installer requests eslint-plugin-yml@^1.19.1 alongside eslint@^8.57.1. Recent eslint-plugin-yml majors declare a peer dependency on eslint@^9, which conflicts with DCQ's pinned eslint@^8.57.1, so the install cannot resolve.

The working fix (confirmed locally) was to pin the plugin down:

ddev npm install --save-dev cspell eslint eslint-config-airbnb-base eslint-config-prettier \
  eslint-plugin-import eslint-plugin-jsdoc eslint-plugin-no-jquery eslint-plugin-prettier \
  eslint-plugin-yml@^1 prettier stylelint stylelint-config-standard stylelint-order stylelint-prettier

eslint-plugin-yml@^1 selects a build whose peer range still includes eslint 8. This added 459 packages with no errors. Suggested change: align the pinned eslint-plugin-yml constraint with the pinned eslint version so the declared dependency set actually resolves.

Bug 2 — version constraints are escaped with a literal backslash

Separately, the install command shell-escapes the caret in each constraint:

ddev npm install --save-dev --package-lock cspell@\^9.8.0 eslint@\^8.57.1 ... stylelint-prettier@\^5.0.3

npm reads the backslash literally:

npm error code EINVALIDTAGNAME
npm error Invalid tag name "\^9.8.0" of package "cspell@\^9.8.0": Tags may not have any characters that encodeURIComponent encodes.

npm treats \^9.8.0 as a dist-tag rather than a semver range. Constraints should reach npm unescaped (build the name@range tokens as an argv array rather than a shell string, or quote the whole token instead of escaping the caret).

Bug 3 — the failure is non-fatal and success is reported anyway

After the failed versioned install, the installer runs a bare ddev npm install:

Installing JS deps in project root using npm (this may take several minutes).
Running: /opt/homebrew/bin/ddev npm install
removed 132 packages, and audited 1 package in 175ms
found 0 vulnerabilities
Node toolchain installed (project root).

That bare install only reconciles already-declared dependencies (note "removed 132 packages" — nothing DCQ-related was added). Despite this, the installer prints Node toolchain installed (project root). and the final summary lists:

What was installed:
  ...
  - Node toolchain (ESLint, Prettier, Stylelint)

So the exit is "success" and the summary claims the toolchain is present, even though the required dev-deps were never installed.

Suggested changes

1. Fix the version constraint (Bug 1): align eslint-plugin-yml with the pinned eslint@^8.57.1 (e.g. eslint-plugin-yml@^1) so the dependency set resolves.
2. Fix the quoting (Bug 2): pass name@range arguments to npm without shell-escaping the ^.
3. Do not report success after a failed install (Bug 3): make the npm-install failure fatal, or after the install verify the required packages are actually present and print a prominent warning (and omit the toolchain from the "What was installed" summary) if any are missing. Do not treat a bare ddev npm install as satisfying the requirement.

The core concern: the current behavior can leave users without the code-quality tooling while telling them it was installed.

Environment

• drupal-code-quality: v1.0.6 (installed from UltraBob/ddev-drupal-code-quality)
• Host: macOS (Darwin, arm64 — homebrew ddev at /opt/homebrew/bin/ddev)
• npm run inside DDEV web container

[UltraBob]

Correction: I've edited the issue body. My original write-up credited the shell-escaping as the fix. That was wrong — the change that actually made the install succeed was pinning eslint-plugin-yml down to ^1 (from the requested ^1.19.1), which resolves the peer-dependency conflict with the pinned eslint@^8.57.1. The shell-escaping is a real but separate bug. The body now lists both, with the version pin as the primary reproducer.

[UltraBob]

Fix is up in #44. One diagnostic correction worth recording:

Bug 1 (the eslint-plugin-yml pin) turned out to be a misdiagnosis — the installer's constraint set was already consistent. Verified against the registry: eslint-plugin-yml@^1.19.1 and @^1 resolve to the same version (1.19.1, the latest 1.x), and its peer range is eslint >=6.0.0, which accepts the pinned eslint@^8.57.1. The versioned install never failed to resolve — it failed because the shell-escaped \^ (Bug 2) meant the constraints never reached npm as semver ranges at all.

The peer conflict in this report came from the manual retry path: after the escaped install failed, the installer's own guidance printed the package list unversioned, and an unversioned install resolves eslint-plugin-yml to 3.x (peer eslint >=9.38.0), which conflicts with eslint-config-airbnb-base (peer eslint 7/8). Adding @^1 fixed that manual command by forcing the resolver back to 1.19.1 — the same version the installer would have requested all along.

So the PR changes no version pins. It fixes the escaping (Bug 2), makes a failed dependency install report as FAILED in the output and summary instead of falling through to a bare npm install and claiming success (Bug 3), and replaces the unversioned retry guidance with the exact versioned command so the manual path can't hit the peer conflict either.