feat: update pnpm and fix stale dependency cache after dep config changes

[zkochan]

Summary

• Update pnpm packages (@pnpm/core 1016.1.0 → 1016.1.8, @pnpm/modules-yaml 1001.0.1 → 1002.0.1)
• Fix a latent bug where set-peer, unset-peer modified dependency configuration without invalidating the filesystem dependency cache. This caused stale cached data to persist — e.g. after set-peer, the next install would still treat the component as a regular dependency instead of a peer.

Test plan

• e2e/functionalities/peer-dependency-component.e2e.ts — "set-peer for existing component" passes

[Copilot]

Pull request overview

This PR claims to "update express and replace request with postman-request", but the actual changes only consist of version updates to various @pnpm packages. The PR has a critical discrepancy between its title/intent and the actual code changes.

Changes:

• Updated multiple @pnpm package versions (client, config, core, default-reporter, dependency-path, fetch, lockfile packages, modules-yaml, npm-resolver, package-store, plugin-commands, sort-packages, store-connection-manager, types, worker, workspace.pkgs-graph)

[Copilot]

The PR title states "fix: update express and replace request with postman-request", but the actual changes only update @pnpm package versions. There are no changes to express (which remains at version 4.21.2 in the workspace) and no changes related to replacing the request package with postman-request. Either the PR title is incorrect, or the PR is incomplete and missing the actual changes described in the title.

[Copilot]

Pull request overview

Copilot reviewed 2 out of 3 changed files in this pull request and generated no new comments.

[Copilot]

Pull request overview

Copilot reviewed 4 out of 5 changed files in this pull request and generated no new comments.

Comments suppressed due to low confidence (2)

scopes/dependencies/dependencies/dependencies.main.runtime.ts:128

• The PR description states that the bug affects "set-peer, unset-peer, deps set, deps remove, deps reset, and deps eject", but only setPeer and unsetPeer received the cache-clearing fix.

The comment on lines 125-127 explains why: "Other dep mutations (setDependency, removeDependency, etc.) don't need this because they only change the component's own .bitmap policy, which dep resolution reads directly; the normal invalidateDependenciesCacheIfNeeded mechanism (checking .bitmap mtime) is sufficient there."

This is architecturally correct - the setPeer/unsetPeer commands are special because they set the "peer: true" config which gets written to the bit.peer field in package.json AFTER dependency resolution runs. Other commands (deps set, deps remove, deps reset, deps eject) only modify the policy field in .bitmap, which is read directly during dependency resolution.

Consider updating the PR description to be more accurate: "Fix a bug where set-peer and unset-peer modified dependency configuration in .bitmap without invalidating the filesystem dependency cache."

    // Other dep mutations (setDependency, removeDependency, etc.) don't need this because they only
    // change the component's own .bitmap policy, which dep resolution reads directly; the normal
    // invalidateDependenciesCacheIfNeeded mechanism (checking .bitmap mtime) is sufficient there.
    await this.workspace.consumer.componentFsCache.deleteAllDependenciesDataCache();

scopes/workspace/modules/node-modules-linker/node-modules-linker.ts:281

• There's a logic issue with the packageJsonCreated flag. On line 269, the condition checks !this.packageJsonCreated && packageJsonExist. However, if the package.json doesn't exist initially (packageJsonExist is false), the code on line 223 sets packageJsonCreated to true. This means the new comparison block (lines 269-281) will never execute in the case where a package.json needs to be created from scratch.

This is actually fine for the current use case, but the flag name is misleading. The flag is now being used to track "should we invalidate the cache" rather than just "was the package.json created". Consider renaming it to shouldInvalidateCache or packageJsonChanged for clarity.

    if (!this.packageJsonCreated && packageJsonExist) {
      try {
        const existingPkgJson = await fs.readJson(packageJsonPath);
        const newPkgJsonStr = JSON.stringify(packageJson.packageJsonObject);
        const existingPkgJsonStr = JSON.stringify(existingPkgJson);
        if (newPkgJsonStr !== existingPkgJsonStr) {
          this.packageJsonCreated = true;
        }
      } catch {
        // if we can't read the existing package.json, treat it as changed
        this.packageJsonCreated = true;
      }
    }

[Copilot]

Pull request overview

Copilot reviewed 4 out of 5 changed files in this pull request and generated 2 comments.

Comments suppressed due to low confidence (1)

scopes/workspace/modules/node-modules-linker/node-modules-linker.ts:276

• The package.json change detection compares JSON.stringify() output, which is sensitive to object key insertion order. If the on-disk JSON property order differs but the data is semantically identical, this will incorrectly mark it as changed and trigger broader cache invalidation. Prefer a deep structural equality check (e.g. lodash/isEqual) or a stable stringify (sorted keys) to avoid unnecessary cache clears.

    if (!this.packageJsonCreated && packageJsonExist) {
      try {
        const existingPkgJson = await fs.readJson(packageJsonPath);
        const newPkgJsonStr = JSON.stringify(packageJson.packageJsonObject);
        const existingPkgJsonStr = JSON.stringify(existingPkgJson);
        if (newPkgJsonStr !== existingPkgJsonStr) {
          this.packageJsonCreated = true;
        }

[Copilot]

PR description says only @pnpm/core and @pnpm/modules-yaml were updated, but this change updates many additional @pnpm/* packages (client/config/default-reporter/dependency-path/fetch/lockfile/*/npm-resolver/package-store/etc.). Please update the PR description to reflect the broader pnpm dependency bump (or reduce the diff if only two packages are intended).

[Copilot]

After clearing the filesystem dependencies cache, the workspace may still serve already-loaded components (and their dependency data) from the in-memory workspace/component loader caches in long-running processes (e.g. IDE server). Consider also calling this.workspace.clearAllComponentsCache() (or at least clearing the affected components) after deleteAllDependenciesDataCache() so subsequent bit show/dependency queries in the same process can't reuse stale component instances.