Description

getPackageManagerConflictWarning interpolates package.json-controlled values
(legacy.name/devEngines.name/legacy.version) directly into warning text that pnpm prints to stderr
without stripping control characters. A malicious repository can embed ANSI escape sequences or
newlines in those fields to forge/mislead terminal or CI log output when the conflict warning is
emitted.

Code

config/reader/src/index.ts[R903-925]

+function getPackageManagerConflictWarning (legacy: ParsedPackageManager, devEngines: ParsedPackageManager): string | undefined {
+  const ignoredSuffix = '. "packageManager" will be ignored'
+  const genericWarning = `Cannot use both "packageManager" and "devEngines.packageManager" in package.json${ignoredSuffix}`
+  if (legacy.name !== devEngines.name) {
+    return `"packageManager" (${legacy.name}) and "devEngines.packageManager" (${devEngines.name}) specify different package managers in package.json${ignoredSuffix}`
+  }
+  if (legacy.version !== devEngines.version) {
+    // "different versions" only makes sense when both sides are concrete
+    // versions. If one side has no semver version — e.g. the legacy field is a
+    // URL or a bare name — fall back to the generic notice rather than claiming
+    // a version mismatch.
+    if (legacy.version == null || devEngines.version == null) return genericWarning
+    return `"packageManager" and "devEngines.packageManager" specify different versions of ${legacy.name} in package.json${ignoredSuffix}`
 }
+  if (legacy.hash !== devEngines.hash) {
+    // Same name and version, but the integrity hashes differ. Two distinct
+    // hashes for one version is a likely wrong-hash mistake, so call it out
+    // specifically; a hash on only one side is a softer mismatch (the version
+    // still agrees) and gets the generic notice.
+    if (legacy.hash != null && devEngines.hash != null) {
+      return `"packageManager" and "devEngines.packageManager" specify ${legacy.name}@${legacy.version} with different integrity hashes in package.json${ignoredSuffix}`
+    }
+    return genericWarning

Evidence

The new warning messages interpolate manifest-derived fields directly into strings, and pnpm prints
these warnings to stderr via console.warn after adding a chalk prefix, without sanitizing the
message body.

config/reader/src/index.ts[903-927]
pnpm/src/getConfig.ts[24-40]
cli/default-reporter/src/reporterForClient/utils/formatWarn.ts[3-5]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`getPackageManagerConflictWarning()` embeds `legacy.name`, `devEngines.name`, and `legacy.version` (read from `package.json`) into human-facing warning strings. These strings are printed to stderr with no sanitization, so control characters (e.g. ANSI escape sequences) or newline characters can be injected into logs/terminals.
### Issue Context
Warnings are rendered with a chalk prefix but the message body is emitted verbatim.
### Fix Focus Areas
- config/reader/src/index.ts[903-925]
### Suggested fix
- Introduce a small helper (local to `getPackageManagerConflictWarning` or nearby) that converts user-controlled fields to a safe, single-line representation before interpolation.
- At minimum: strip VT/ANSI control characters (e.g. `stripVTControlCharacters` from `node:util`) and replace `\r`/`\n` with escaped sequences or spaces.
- Apply the helper to `legacy.name`, `devEngines.name`, and `legacy.version` in all returned warning strings.
### Acceptance criteria
- Conflict warnings remain semantically the same for normal inputs.
- Inputs containing control characters/newlines do not cause multi-line output or terminal escape injection.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

🐞 Bugs (1) 📘 Rule violations (0)

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0)

Great, no issues found!

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0)

Great, no issues found!

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0)

Great, no issues found!

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0)

Great, no issues found!

Walkthrough

Parses packageManager specifiers including semver build-metadata hashes and compares name, version, and hash to emit precise warnings only for true divergences between packageManager and devEngines.packageManager.

Changes

Hash-aware packageManager conflict detection

Sequence Diagram

sequenceDiagram
  participant ConfigReader as Config Reader
  participant Parser as parsePackageManager
  participant Splitter as splitPackageManagerVersion
  participant Detector as getPackageManagerConflictWarning
  participant Warnings as warnings

  ConfigReader->>Parser: parse legacy `packageManager` spec
  Parser->>Splitter: split version and +hash
  Splitter-->>Parser: return name, version, hash
  ConfigReader->>Parser: parse `devEngines.packageManager` spec
  ConfigReader->>Detector: pass legacyParsed, devEnginesParsed
  Detector->>Detector: compare name, version, hash
  alt identical name+version+hash
    Detector-->>Warnings: no warning
  else name mismatch
    Detector-->>Warnings: "specify different package managers"
  else version mismatch
    Detector-->>Warnings: "specify different versions of pnpm"
  else hash mismatch
    Detector-->>Warnings: "different integrity hashes"
  end

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

Suggested reviewers

• zkochan

Poem

🐰 I hop through specs with careful art,
I split the version and the hash apart,
When name, version, and hash all align,
No needless warning will you find,
Only true mismatches get my bark.

❌ Failed checks (1 warning)

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

• X
• Mastodon
• Reddit
• LinkedIn

• Parse and compare package manager version *and* integrity hash to avoid false conflict warnings.
• Emit more specific conflict warnings for differing managers, versions, or contradictory hashes.
• Add unit/integration tests and a changeset covering the new warning behavior.

The following are alternative approaches to this PR:

Recommendation: Keep the PR’s structured comparison (name + semver part + optional hash). It fixes the false-positive warning while preserving safety (warn on any divergence) and improves UX via specific diagnostics for manager/version/hash mismatches.

index.ts Compare package manager specs structurally (including integrity hash) +58/-10

Compare package manager specs structurally (including integrity hash)

• Extends parsePackageManager to retain semver build metadata as an integrity hash and factors out splitPackageManagerVersion. Adds getPackageManagerConflictWarning to suppress warnings only on exact matches and to emit more specific warnings for different managers, versions, or contradictory hashes.

config/reader/src/index.ts

---

index.ts Add unit coverage for packageManager/devEngines conflict warnings +63/-0

Add unit coverage for packageManager/devEngines conflict warnings

• Adds a focused test suite covering no-warning scenarios (including matching hashes) and the three warning categories: generic hash-present-on-one-side, contradictory hashes, version mismatch, and manager mismatch.

config/reader/test/index.ts

---

packageManagerCheck.test.ts Expand integration tests for hash-aware conflict warnings +60/-3

Expand integration tests for hash-aware conflict warnings

• Updates existing assertions to match the new, more specific warning text and adds integration coverage for matching hashes, contradictory hashes, and hash-only-on-legacy scenarios.

pnpm/test/packageManagerCheck.test.ts

---

devengines-package-manager-same-hash.md Add changeset documenting hash-aware warning suppression +8/-0

Add changeset documenting hash-aware warning suppression

• Introduces a patch changeset for @pnpm/config.reader and pnpm describing the removal of spurious warnings when both fields match including integrity hash, and outlining the remaining divergence cases.

.changeset/devengines-package-manager-same-hash.md

---