bit scope rename re-introduces MissingManuallyConfiguredPackages for forked envs (regression of #10200)

[zkochan]

Summary

After PR #10201 fixed MissingManuallyConfiguredPackages when running bit new / bit fork on an env that uses "+" dependency markers, the same error re-surfaces after running bit scope rename --refactor on the default scope. The scenario originally surfaced with the Vue starter (my-vue-env extends bitdev.vue/vue-env which declares @mdx-js/mdx as a peer).

Related: #10200, #10201

Reproduction

Branch: fix/scope-rename-missing-deps

A new e2e test has been added in e2e/harmony/dependencies/forked-env-missing-deps.e2e.ts that covers two cases:

1. Forking an env with "+" markers in its dep-resolver config, then running bit scope rename --refactor.
2. Forking an env that extends a parent env declaring the peer (the actual Vue starter shape), then running bit scope rename --refactor.

In both cases, bit status incorrectly reports MissingManuallyConfiguredPackages for the forked env after the rename, even though the package is resolved (either in workspace node_modules or through the parent env's peer policy).

Progress

• Create branch fix/scope-rename-missing-deps
• Write e2e regression test (currently describe.only locally for iteration)
• Investigate root cause — why bit scope rename --refactor reintroduces the false-positive that fix: Missing Packages After bit new with Forked Env #10201 resolved for bit new. Suspected: after the rename, the forked env's component config is rewritten and the resolution path that applyAutoDetectedPeersFromEnvOnEnvItSelf relies on is no longer hit, so getDependenciesToAddManually() falls back to the failing _manuallyAddPackage() path.
• Implement fix
• Remove describe.only and run lint + targeted e2e

Notes

• The e2e test uses the same shape as the fix: don't install dependencies of the env as dependencies of the user component #10150 regression test already in that file.
• For the parent/child env case, is-positive is used as the peer (avoids pulling in real Vue packages).

[zkochan]

Key finding — #10201 fix is already broken on master

Ran the e2e regression test from PR #10201 (unchanged, before any scope-rename additions) against current master (75e1dca0c). Both tests fail:

forked env with "+" dependency markers (PR #10150 regression)
  fork an env whose dep-resolver config has "+" entries for env peer packages
    1) bit status should not have MissingManuallyConfiguredPackages issue for the forked env
    2) bit status should not have any component issues

Assertion: expected [ 'MissingManuallyConfiguredPackages' ] to not include 'MissingManuallyConfiguredPackages'

So the original #10201 fix for bit new/bit fork no longer holds on master. The scope-rename failures observed in the Vue starter are almost certainly a downstream symptom of this broader regression, not a separate scope-rename-only bug.

Commits on master after #10201 landed (e99f3a7)

No commits directly touching scopes/dependencies/dependencies/dependencies-loader/apply-overrides.ts. Only #10318 touched the dependency-resolver scope (lockfile preservation on reimport). Next step: bisect from #10201 forward to find the commit that regressed the fix — candidates worth trying first are the deps-graph lockfile PR and any env/peer related changes.

Plan update

1. Bisect to identify the commit that broke the fix: Missing Packages After bit new with Forked Env #10201 fix.
2. Fix the regression at its source rather than patching the scope-rename path separately.
3. Keep both e2e test scenarios (bit fork baseline and after scope rename) as regression guards.

[zkochan]

Diagnostic run — confirmed is-positive surfaces as missing

Ran the baseline PR #10201 test standalone with a console.log of statusJson().componentsWithIssues:

DBG forked status: [
  {
    "id": "787c197c-remote/my-forked-env",
    "issues": [
      {
        "type": "MissingManuallyConfiguredPackages",
        "isTagBlocker": true,
        "data": [ "is-positive" ]
      }
    ]
  }
]

Investigation so far

1. Re-checked scopes/dependencies/dependencies/dependencies-loader/apply-overrides.ts and scopes/dependencies/dependency-resolver/manifest/workspace-manifest-factory.ts at the PR fix: Missing Packages After bit new with Forked Env #10201 merge commit e99f3a7e5 — identical to current master. No textual regression in the fix.
2. Confirmed compiled node_modules/@teambit/dependencies/dist/dependencies-loader/apply-overrides.js still contains missingPkgRemovals (4 occurrences) — the compiled fix is present.
3. No commits touching scopes/dependencies/dependencies/dependencies-loader/ or relevant peer-resolution code since the PR merged (only PRs fix(deps-graph): preserve workspace lockfile entries on reimport #10318, feat(tester): agent-friendly bit test output with per-component rollup #10313, feat(preview): add supportsUseSource env preview config #10321, ci: replace eslint with oxlint for repo linting #10324, etc., none touching the fix).

Hypothesis

Either:

• applyAutoDetectedPeersFromEnvOnEnvItSelf() is not populating allPackagesDependencies.packageDependencies['is-positive'] for my-forked-env (so the fix: Missing Packages After bit new with Forked Env #10201 fallback in getDependenciesToAddManually() has nothing to match against), or
• The order of manuallyAddDependencies() vs applyAutoDetectedPeersFromEnvOnEnvItSelf() is inverted in some code path the test hits.

Next step requires source-level instrumentation inside those two methods to print the state of allPackagesDependencies at the moment getDependenciesToAddManually() evaluates the fallback.

Branch state

fix/scope-rename-missing-deps has the e2e test file updated with:

• The after-rename nested describe for the simple forked-env case.
• A second top-level describe for the parent-env / child-env fork (Vue starter shape) — currently has a fixture setup error (parent-env fixture doesn't exist), needs a valid fixture-extensions subdir or an inline env that extends a preexisting env fixture.

Pausing here before implementing a fix — the root cause is broader than the scope-rename path and needs the instrumentation above to pin down.

[zkochan]

Major update — earlier conclusion was wrong

The regression claim in my previous comment was a false alarm. The e2e tests pick bit as the bin by default (per e2e-command-helper.ts line 76), which on this machine is the bvm-managed global bit at ~/.bvm/links/bit/ — that binary dates from 2026-03-18 and predates PR #10201. That's why the #10201 tests appeared to fail: they were running against a binary that didn't have the fix.

Re-ran with npm_config_bit_bin=bd (dev-linked bit pointing at the repo's @teambit/bit/dist/app) and added file-based instrumentation to node_modules/.../apply-overrides.js (plus the two .pnpm/... copies). Confirmed:

• applyAutoDetectedPeersFromEnvOnEnvItSelf() runs and populates allPackagesDependencies.packageDependencies['is-positive'] = '3.1.0'.
• getDependenciesToAddManually() hits _manuallyAddPackage('is-positive', '+'), which fails and pushes is-positive to missingPackageDependencies.
• The fix: Missing Packages After bit new with Forked Env #10201 fallback matches (pkgDeps['is-positive'] = '3.1.0'), missingPkgRemovals.add('is-positive') runs, and the filter at end of the function removes it.
• Logged [DBG] REMOVING is-positive from missingPkg confirms this runs on every invocation for the forked env (both pre- and post-rename).

But bit status STILL reports MissingManuallyConfiguredPackages: ['is-positive'].

New finding

Instrumented setDependenciesDataOnComponent in dependencies-loader.js. For my-forked-env, overridesDependencies.missingPackageDependencies at the point of issue assignment is:

["core-js","@babel/runtime","@types/node","@types/react","@types/react-dom",
 "@types/jest","@types/testing-library__jest-dom","react","react-dom"]

Notably is-positive is NOT present — the #10201 fix cleanly removed it. Yet the issue the test sees contains only is-positive.

So the status's MissingManuallyConfiguredPackages: ['is-positive'] is NOT produced by dependencies-loader.ts:167 (the only getOrCreate(MissingManuallyConfiguredPackages) call in the tree). The data is coming from somewhere else — possibly a stale persisted Extension/ExtensionDataEntry on the component (likely teambit.component/issues), or a cached snapshot from when the env was tagged in the source workspace.

Next step: grep for any other writer of data = [...] on MissingManuallyConfiguredPackages or any persistence path that stores an issues snapshot per-component (e.g., model extensions, scope cache).

[zkochan]

Resolution — there is no scope-rename regression

When the e2e is run with npm_config_bit_bin=bd (dev-linked bit pointing at the repo's compiled code, which contains PR #10201), all 4 scope-rename + fork assertions pass:

  forked env with "+" dependency markers (PR #10150 regression)
    fork an env whose dep-resolver config has "+" entries for env peer packages
      ✔ bit status should not have MissingManuallyConfiguredPackages issue for the forked env
      ✔ bit status should not have any component issues
      after "bit scope rename --refactor" of the default scope
        ✔ bit status should not have MissingManuallyConfiguredPackages issue for the forked env
        ✔ bit status should not have any component issues

Root cause of the earlier apparent "regression": e2e-command-helper.ts defaults bitBin to bit when invoked via mocha, which resolves to the machine's global bvm-managed bit. On this machine that link points at a version from 2026-03-18, well before PR #10201 merged (2026-04-21). Running the tests against that stale binary produced the MissingManuallyConfiguredPackages: ['is-positive'] failure.

What's left

1. The scope-rename case described in the original issue title does not reproduce on current master.
2. The second describe (parent-env/child-env fork, the real Vue starter shape) still has a setup error because setCustomNewEnv expects a fixture directory at excluded-fixtures/extensions/parent-env that doesn't exist — this is a test-scaffolding problem, not a product bug. It should be rewritten to construct the parent env inline rather than via setCustomNewEnv.
3. Original user report about @mdx-js/mdx being marked missing after bit scope rename on the Vue starter may still be real when the user's installed bit predates fix: Missing Packages After bit new with Forked Env #10201. The fix is: users on affected versions should upgrade to a bit release that contains fix: Missing Packages After bit new with Forked Env #10201.

Recommendation

Close this issue as not-a-bug on master. Leave the scope-rename nested describe in e2e/harmony/dependencies/forked-env-missing-deps.e2e.ts as a regression guard (it passes today). Drop the parent-env/child-env second describe or rewrite it with a working fixture.

[zkochan]

Reopening — simplified e2e doesn't reproduce the real case

My earlier "not a bug on master" conclusion was based on a simplified e2e where the forked env's own env.jsonc declared the "+" peer. That case does pass after PR #10201 — both before and after bit scope rename.

The real-world failing scenario (from user's terminal log) is structurally different:

bit new vue-hello-world my-vue-hello-world --aspect teambit.community/starters/hello-world-vue
bit status         # OK
bit scope rename org.scope-name my-org.my-scope-name --refactor
bit link && bit compile
bit status         # FAILS: @mdx-js/mdx missing on my-org.my-scope-name/envs/my-vue-env

Here my-vue-env extends bitdev.vue/vue-env via env.jsonc's extends field — @mdx-js/mdx is declared as a peer on the parent env, not on my-vue-env directly. Pre-rename, applyAutoDetectedPeersFromEnvOnEnvItSelf can still resolve @mdx-js/mdx through the parent env's selfPolicy. Post-rename something breaks that resolution, surfacing the false MissingManuallyConfiguredPackages.

Interesting ambient signal in the user's log: ⚠ env "org.scope-name/envs/my-vue-env" is not of type env fires both before and after the rename, so env loading is already unhealthy. But only after rename does the @mdx-js/mdx missing issue appear.

Working hypothesis

bit scope rename --refactor rewrites sourcePkg → targetPkg for renamed components via replaceMultipleStrings. For the forked env's env.jsonc, that may be updating the extends reference or related metadata in a way that makes the parent-env peer policy un-resolvable for applyAutoDetectedPeersFromEnvOnEnvItSelf. The #10201 fallback then has nothing to match against (allPackagesDependencies.packageDependencies['@mdx-js/mdx'] is unset), so is-positive/@mdx-js/mdx stays in missingPackageDependencies.

Next steps

1. Write an e2e that creates a parent-env + child-env (child extends parent) pair, exports them, forks the child, then runs bit scope rename --refactor on the default scope. Use the react-based-env fixture dir (exists) as the base for both, with distinct targetFolder/id. My earlier attempt at this failed because I passed non-existent fixture names — fixable.
2. If that e2e reproduces, instrument applyAutoDetectedPeersFromEnvOnEnvItSelf under bd to confirm whether envPolicy.selfPolicy still contains the parent's peer after rename.

[zkochan]

Root cause identified

The #10201 fix is irrelevant to this failure. The @mdx-js/mdx declaration on my-vue-env is a regular peer with a concrete version (1.6.22), NOT a "+" sentinel — so the #10201 fallback never runs.

What actually happens

In apply-overrides.ts:getDependenciesToAddManually(), the if (addedPkg) branch still pushes to missingPackageDependencies when componentData.packageName is undefined:

const addedPkg = this.overridesDependencies._manuallyAddPackage(...);
if (addedPkg) {
  packages[depField] = Object.assign(...);
  if (componentData && !componentData.packageName) {   // <-- fires for @mdx-js/mdx post-rename
    this.overridesDependencies.missingPackageDependencies.push(dependency);
  }
}

componentData.packageName comes from _resolvePackageData(pkgName) which uses node's module resolution starting at the component's rootDir. It succeeds when the package is resolvable from that base path, otherwise returns undefined.

The pre/post diff — verified via instrumentation

Same bd status, same override dependency (@mdx-js/mdx: 1.6.22), same addedPkg. Only componentData.packageName differs:

• Pre-rename: componentData.packageName = "@mdx-js/mdx". The package is present at scope-name/envs/my-vue-env/node_modules/@mdx-js/mdx (pnpm hoisted it into the component's own node_modules during bit install).
• Post-rename: componentData.packageName = undefined. The component dir was renamed to my-scope-name/envs/my-vue-env, but its per-component node_modules/ wasn't. @mdx-js/mdx is only in .pnpm/ virtual store, not hoisted to workspace-level, so the new basePath can't resolve it.

Crucially, only some peers hit this. E.g. @mdx-js/react is ALSO hoisted to top-level node_modules/@mdx-js/react, so it stays resolvable. @mdx-js/mdx isn't hoisted at workspace root — only into per-component isolated trees. Post-rename, those isolated trees for the renamed components no longer match the component's new rootDir.

Workaround

Running bit install after bit scope rename --refactor regenerates the isolated tree at the new path and fixes the issue. Confirmed locally.

Code path

scopes/component/renaming/renaming.main.runtime.ts:188 currently calls linkToNodeModulesByComponents + compileGracefully after rename. Neither re-runs pnpm install, so per-component node_modules stays orphaned.

Fix options

1. Run install after renameMultiple — heaviest but most correct. Slow.
2. Relocate or rebuild each renamed component's local node_modules (copy the old dir to the new path, or call pnpm's per-project linker for the renamed components). Narrower scope than (1).
3. Document it — tell users to run bit install after bit scope rename --refactor. Cheapest but fragile.
4. Narrower: widen the if (addedPkg && !componentData.packageName) push-to-missing condition to NOT push when allPackagesDependencies.packageDependencies[dependency] already has a resolved version (extension of fix: Missing Packages After bit new with Forked Env #10201's logic). This makes the symptom go away but ignores the underlying orphaned node_modules — preview/build might still fail until install runs.

My preference: (1) OR (2). I would like to draft (1) first since it is the simplest correct fix. But I want to confirm this approach with you.