installing/env-installer/src/installConfigDeps.ts:295

• reportStarted is only called on fetch/import and rimraf paths, but installOptionalSubdeps can still do real filesystem work by (re)creating sibling symlinks via symlinkDir (e.g. when a sibling link is missing/stale but the package is already in the store). In that case this change will suppress the "Installing config dependencies..." banner even though work was performed. Consider using symlinkDir’s return value ({ reused }) to call reportStarted only when the link was actually created/replaced, so no-op symlink checks stay quiet but repairs are still reported.

  await Promise.all(compatibleSubdeps.map(async (subdep) => {
    const subdepFullPkgId = `${subdep.name}@${subdep.version}:${subdep.resolution.integrity}`
    const subdepRelPath = calcLeafGlobalVirtualStorePath(subdepFullPkgId, subdep.name, subdep.version)
    const subdepDirInGlobalVirtualStore = path.join(opts.globalVirtualStoreDir, subdepRelPath, 'node_modules', subdep.name)
    if (!fs.existsSync(path.join(subdepDirInGlobalVirtualStore, 'package.json'))) {
      opts.reportStarted()
      const { fetching } = await opts.store.fetchPackage({

installing/env-installer/src/installConfigDeps.ts (1)

310-312: 💤 Low value

Consider whether subdep symlink creation should trigger the banner.

The code calls symlinkDir for subdeps (line 312) without a direct reportStarted() call. In contrast, parent symlink creation (line 119) triggers reportStarted() on line 114 when the symlink is missing or incorrect. This asymmetry means:

• If a parent symlink is missing → banner appears
• If a subdep symlink is missing (but package exists) → silent operation

This appears intentional based on the PR description listing only five reportStarted() call sites without mentioning subdep symlink creation, but it's worth confirming this design choice.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@installing/env-installer/src/installConfigDeps.ts` around lines 310 - 312,
The subdependency symlink creation using symlinkDir for subdeps (where linkPath
= path.join(opts.parentNodeModulesDir, subdep.name)) currently doesn't call
reportStarted(), unlike the parent symlink branch that calls reportStarted()
around parent symlink creation; add a reportStarted() invocation (with the same
banner message/context used for parent symlinks) immediately before creating the
subdep symlink so missing/incorrect subdep symlinks also trigger the banner, or
if this was intentional add a clear inline comment referencing symlinkDir and
reportStarted to document the asymmetry—update code around symlinkDir, linkPath,
and opts.parentNodeModulesDir accordingly.

installing/env-installer/test/resolveAndInstallConfigDeps.test.ts:265

• The new reportStarted() gating has several distinct "work" paths (e.g. orphan cleanup when a config dep is removed, and orphan optional-subdep sibling cleanup). This test only covers fresh install (started+done) and a fully no-op rerun (no events). Adding an assertion for the removal/cleanup path (expecting a started event when a previously-installed config dep is removed) would help prevent regressions in the exact behavior this PR is changing.

test('emits installing-config-deps events only when work is needed', async () => {
  prepareEmpty()
  const opts = createOpts()

  takeConfigDepEvents()
  await resolveAndInstallConfigDeps({
    '@pnpm.e2e/foo': '100.0.0',
  }, opts)
  const firstRunEvents = takeConfigDepEvents()

  expect(firstRunEvents.map(e => e.status)).toEqual(['started', 'done'])
  expect(firstRunEvents.find(e => e.status === 'done')?.deps).toEqual([
    { name: '@pnpm.e2e/foo', version: '100.0.0' },
  ])

  await resolveAndInstallConfigDeps({
    '@pnpm.e2e/foo': '100.0.0',
  }, opts)
  const secondRunEvents = takeConfigDepEvents()

  expect(secondRunEvents).toStrictEqual([])
})