Finding Unused Transitive Packages with Dynamic Import Tracing

Your lockfile declares eighteen direct dependencies, but resolves 1,400 packages. When a vulnerability alert fires on a transitive package five levels deep in that dependency tree, your team spends half a day answering a simple question: does our application ever actually invoke this code?

Static analyzers and AST parsers can only trace explicit import declarations. They fail on conditional require() statements buried in vendor shims, dynamic import() calls driven by environment variables, and bulky polyfills bundled defensively for browsers nobody uses. The result is uncalled dead code sitting in production bundles, inflating attack surface and triggering compliance alerts for logic that never runs.

A dependency manifest states what could be loaded. It does not tell you what runs.

Intercepting module resolution at test time

To determine which transitive packages are load-bearing, you have to watch the runtime load them. Static inspection inspects potential reachability; dynamic tracing logs real reachability.

In Node.js, you can instrument module resolution using runtime hooks (module.register or custom loaders) during integration and end-to-end test runs. Every time the engine resolves a file inside node_modules, the hook logs the target package name.

// trace-loader.mjs
import { isBuiltin } from 'node:module';

export async function resolve(specifier, context, nextResolve) {
  const result = await nextResolve(specifier, context);
  if (!isBuiltin(result.url) && result.url.includes('/node_modules/')) {
    const match = result.url.match(/node_modules\/((?:@[^/]+\/)?[^/]+)/);
    if (match) {
      process.send?.({ type: 'RESOLVED_PKG', name: match[1] });
    }
  }
  return result;
}

Running your integration suite with --import ./trace-register.mjs outputs the exact set of packages loaded across your test paths.

Dynamic tracing has one obvious limit: test coverage. If your tests do not exercise an error branch, tracing will mark the error-handling package as uncalled. You cannot use dynamic tracing in isolation without an adequate test suite; dynamic traces must be treated as a floor of known-used packages, not an absolute ceiling.

From package counts to an honest software inventory

A list of directories inside node_modules is not an inventory; it is a list of download artifacts. As we explore in our doctrine on why a component count is not an inventory, an entry only belongs in your inventory if you can verify its execution.

When teams diff dynamic traces against their lockfile, they routinely find transitive packages that are never loaded. They exist because an upstream SDK author included multiple database drivers when you only use Postgres, or bundled an entire logging framework as an optional fallback.

Tracing turns vague vendor bloat into actionable categories:

1. Load-bearing packages: Resolved and executed during tests.
2. Conditional fallbacks: Unresolved in main paths, requiring targeted tests to verify reachability.
3. Dead weight: Transitive dependencies bundled solely because of unpruned package exports upstream.

Once you know which dependencies never execute, you can replace sprawling omnibus SDKs with focused, single-purpose utilities. You can also pair dynamic import tracing with executable registry audits to systematically remove dead code before it hits production.

How SHPBL verifies software capability

SHPBL approaches this problem at the source. Instead of importing opaque dependency graphs, we harvest discrete capability directly from existing repositories and ship it as model-independent, owned software. No AI model runs inside the artifacts or governs their runtime behaviour; the code is computed and verified.

Every harvested component is executed inside a certification harness that records an explicit verdict:

• CERTIFIED: The component passed execution tests against its contract.
• PROVISIONAL: The component builds and reproduces byte-for-byte, but functional correctness is not yet fully asserted.
• INCONCLUSIVE: The harness could not exercise the input contract due to test harness limitations.
• FAILED: The component failed execution or invariant checks.

We keep our inventory numbers unbundled. We report counts for the engineered catalog, the discovery-engine vault (first-party pipeline output over a 40-primitive matrix, not yet promoted to catalog software), and standalone Crown Jewels separately.

Integration runs through a single method across four interfaces: the @shpbl/sdk TypeScript client, a plain HTTP API, an MCP server, and an offline edition that runs directly from local files. Any agent write passes through a Build Intent gate to resolve licensing and verify invariants in code before terminal state execution.

You can run a free repository evaluation to map your dependency footprint. Access to the full certification gauntlet is available on the Practitioner tier for $39/month, or you can purchase outright ownership of the Complete Master Library for $499.