Summary

When libraries are renamed, removed, or moved in an Nx monorepo, older scan data can remain active in the workspace. This leads to “ghost packages”.

In practice, the workspace continues to treat obsolete package identities as active because they were present in earlier scans. If those older identities are spread across many scans, cleanup becomes difficult because removal currently happens at scan level rather than package level.

What is meant by “ghost package”

A ghost package is a package entry that:

• existed in one or more older scans
• no longer exists in the repository under that identity
• still appears in the workspace as part of current analysis

Typical cases:

• package rename: @scope/orders-feature-receipts → @scope/receipts-feature
• package removal: @scope/orders-shared is deleted from the monorepo
• package move/refactor: a library is relocated and redefined, but the old package identity remains visible in workspace results

Why this is a problem

Ghost packages create the impression that the workspace still contains libraries that are already gone. This affects:

• package visibility in the UI
• aggregated analysis results
• component/package counts
• trust in scan accuracy
• cleanup effort during refactoring or migration projects

This is especially problematic when historical scans are used for ongoing adoption or migration tracking, because obsolete packages can distort the current state of the workspace.

Environment

• Monorepo setup: Nx
• Scan source: repeated scans of the same workspace over time
• Affected scenario:
  • library/package rename
  • library/package removal
  • library/package move to another location
• Workspace behavior:
  • scan history is retained
  • analysis is aggregated across scans in the workspace

Current behavior

• Older package identities remain visible after repository refactoring.
• A renamed package can appear twice:
  • once under the old package name
  • once under the new package name
• Removed packages can still appear in the workspace as if they still exist.
• Moved libraries can remain associated with outdated package metadata.
• Data issue reporting can continue to reference ghost packages even when the corresponding package no longer exists in the codebase.
• Users cannot remove a package from all affected scans directly; cleanup requires deleting complete scans.
• If a ghost package exists in many scans, deleting all affected scans may remove a large amount of still-valid analysis data.

Steps to reproduce

1. Create an Nx monorepo with libraries such as:
   • @scope/orders-feature-receipts
   • @scope/orders-shared
2. Run a scan and upload the results.
3. Refactor the repository:
   • rename @scope/orders-feature-receipts to @scope/receipts-feature
   • remove @scope/orders-shared
   • move another library to a different path
4. Run a new scan and upload the results.
5. Open the workspace analysis or package-related issue view.

Actual result

The workspace can still show:

• @scope/orders-feature-receipts
• @scope/orders-shared

even though these packages no longer exist in the repository.

In addition:

• the renamed package may appear as a new package instead of replacing the old identity
• the old package identity may continue to be referenced in data issues
• cleanup may require deleting many scans that also contain valid and still-needed analysis data

Expected result

• Active workspace analysis should reflect the current package state of the repository.
• Historical scans may remain stored, but obsolete package identities should not continue to appear as active packages.
• Renamed, removed, or moved libraries should be reconciled across scans.
• Users should be able to remove stale package identities without deleting complete scans.

Impact

• Outdated workspace analysis
• Inflated package/component counts
• Confusing issue reporting for packages that no longer exist
• High cleanup cost when ghost packages are present in many scans
• Potential loss of useful historical analysis when removing full scans is the only available workaround

Suggested solution

• Reconcile package identity changes across scans
• Detect likely rename/move relationships in Nx monorepos
• Support targeted removal of a package identity from workspace results without deleting full scans
• Add a reindex/reconciliation option after monorepo restructuring
• Separate historical scan retention from current workspace package state

Additional context

A related limitation is that package names are stored as part of scans, and a single scan can contain multiple packages. Because of that, removing one outdated package currently may require deleting whole scans instead of cleaning up only the obsolete package identity.

This makes ghost packages hard to resolve in real monorepos where:

• many scans exist over time
• branches contribute scans into the same workspace
• package renames and moves are part of normal refactoring

The result is that an obsolete package can survive in workspace analysis long after it was removed from the repository.