• Resolve ESM-only presets in Yarn Plug'n'Play projects via the PnP API.
• Preserve existing node_modules manifest-walk fallback for non-PnP installs.
• Add regression coverage for PnP-based pure-ESM preset resolution.

graph TD
  A["resolveFrom()"] --> B["resolveEsmOnly()"] --> C{{"pnpapi"}} --> E["resolveEsmPackage()"] --> F[("package.json + files")]
  B --> D["node_modules walk"] --> E
  subgraph Legend
    direction LR
    _fn["Function"] ~~~ _ext{{"External API"}} ~~~ _fs[("Filesystem")]
  end

Loading

The following are alternative approaches to this PR:

1. Use pnpapi.resolveRequest for full path resolution

• ➕ Delegates more of the resolution semantics to Yarn's resolver
• ➕ Potentially handles edge cases beyond package-root lookup (e.g., complex subpaths)
• ➖ API behavior/availability can vary across Yarn versions and environments
• ➖ Still may need custom handling for ESM-only exports depending on return values

2. Adopt a dedicated resolver library with PnP + exports support

• ➕ Avoids maintaining custom resolution rules
• ➕ May provide better parity with Node resolution behavior
• ➖ Adds dependency weight and potential behavior changes
• ➖ Harder to control backward-compatible fallbacks (node_modules + custom manifest logic)

Recommendation: The PR’s approach is the best fit: opportunistically use pnpapi when available, then reuse the existing node_modules walk. It minimizes dependencies, keeps backward compatibility, and limits the PnP-specific logic to a small, well-guarded block (try/catch) while sharing the actual ESM entry computation via a single helper.

Bug fix (1) +49 / -19

index.tsResolve ESM-only presets via Yarn PnP before node_modules walk +49/-19

Resolve ESM-only presets via Yarn PnP before node_modules walk

• Extracts shared ESM package resolution into resolveEsmPackage(). Enhances resolveEsmOnly() to first query pnpapi.resolveToUnqualified() using the parent path, then falls back to the existing node_modules traversal when PnP is unavailable or does not resolve.

@commitlint/resolve-extends/src/index.ts

Tests (1) +41 / -0

index.test.tsAdd Yarn PnP regression test for pure-ESM preset resolution +41/-0

Add Yarn PnP regression test for pure-ESM preset resolution

• Introduces a PnP-style fixture scaffold (fake .yarn/cache layout plus a stub pnpapi module). Adds a new test asserting that resolveFrom() can locate an ESM-only preset via the PnP API.

@commitlint/resolve-extends/src/index.test.ts

Description

In the pure-ESM fallback, resolveEsmOnly unconditionally loads "pnpapi" via localRequire and
suppresses all exceptions, which can mask genuine PnP resolution/runtime errors and makes failures
hard to diagnose. It also means a resolvable third-party "pnpapi" package (non-PnP) would be
executed on this fallback path rather than only when actually running under PnP.

Code

@commitlint/resolve-extends/src/index.ts[R106-109]

+	try {
+		const pnpApi = localRequire("pnpapi") as {
+			resolveToUnqualified(
+				request: string,

Evidence

The new PnP resolution branch loads pnpapi and discards all errors, and it is executed from
resolveFrom’s fallback path when standard resolution fails. resolveFrom is invoked for resolving
presets/configs from user config, so this silent failure affects real-world debugging.

@commitlint/resolve-extends/src/index.ts[93-139]
@commitlint/resolve-extends/src/index.ts[142-184]
@commitlint/resolve-extends/src/index.ts[261-266]
@commitlint/resolve-extends/src/index.ts[309-332]

Agent prompt

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

### Issue description
`resolveEsmOnly` attempts `localRequire("pnpapi")` and wraps the whole PnP branch in `catch {}`. This hides unexpected PnP API failures and can also load an unintended `pnpapi` dependency in non-PnP projects.

### Issue Context
This code path runs when normal `require.resolve` and `resolve-from` fail (e.g., pure-ESM packages with import-only `exports`). `resolveFrom` is called as part of resolving user configuration (extends/parser presets), so diagnostics matter.

### Fix Focus Areas
- @commitlint/resolve-extends/src/index.ts[93-139]

### Suggested fix
- Only attempt the PnP resolution branch when actually running under PnP (e.g., by checking a Node-provided PnP indicator such as `process.versions.pnp` or an equivalent Node API).
- Narrow the catch handling:
 - Ignore “module not found” for `pnpapi` as an expected non-PnP case.
 - For other errors (loading `pnpapi`, calling `resolveToUnqualified`, reading manifests), emit a debug log when `process.env.DEBUG === "true"` before falling back to `node_modules` walking.
- Keep the behavior of falling back to `node_modules` lookup when PnP isn’t available.

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