Why Registry Metadata Lies About Component Health

A package manifest says an export exists. The component registry reports a green badge, valid TypeScript declarations, and zero open issues. Then a developer imports the module into production code, and the runtime crashes immediately with a TypeError: default is not a function or silently returns an empty object.

Metadata describes an author's intention, not runtime behavior. When organizations build a software inventory by scraping package manifests, directory trees, or schema declarations, they catalog intentions. The result is an inventory bloated with unvalidated stubs, broken export maps, and dead code that fails the moment it receives real data.

Manifest declarations are aspirations

A package manifest is a static document. It records version numbers, export paths, licensing tags, and dependency bounds. None of these fields assert that the underlying code can initialize, parse an argument, or complete execution.

Three specific failures regularly pass through manifest-based registry scrapers undetected:

1. Dead entrypoints. An export map points to ./dist/formatters/index.js, but a build tool refactor changed the output target to ./dist/formatters.js. TypeScript declarations may still align if generated from source, but the runtime bundle is missing or empty.
2. Hollow stubs. During API transitions, teams frequently leave placeholder functions that return hardcoded defaults or throw NotImplementedError. Traditional dead code detection tools ignore these because the functions are exported and technically referenced. The manifest lists them as active capabilities, but they cannot do work.
3. Implicit runtime dependencies. An entrypoint imports a global variable, an unlisted peer dependency, or an environment variable that exists only on the author's local machine. Static analysis verifies that the syntax is valid, yet execution fails instantly in an isolated environment.

When a component registry tracks these artifacts without running them, it promotes liabilities as reusable assets.

Why static checks miss unexecutable code

Static linters and abstract syntax tree (AST) parsers are designed to verify grammar, structural integrity, and type contracts. They answer the question: Could this text be valid code?

They do not answer the operational question: Does this function execute its input contract and return a valid result in clean isolation?

// Passes syntax checks. Passes type checks. Fails in runtime isolation.
export function normalizePayload(input: unknown): Record<string, unknown> {
  if (typeof window === "undefined") {
    // Left behind during an uncompleted SSR migration
    return {};
  }
  return deepClone(input, window.__CONFIG_SCHEMA__);
}

A registry that reads the AST for normalizePayload registers a working utility function. If the codebase runs in a worker or server environment, it returns an empty object on every call.

As argued in a component count is not an inventory, counting exported symbols creates an illusion of engineering depth. A software inventory only reflects reality when catalog verification requires executing the entrypoint against boundary inputs in a clean process. If an export cannot be invoked in isolation, it is not catalog software; it is unresolved source code.

How SHPBL verifies components

At SHPBL, catalog verification is strictly active. We do not count rows in a package manifest or trust export declarations. Every component in the catalog is model-independent and computed rather than generated.

Code passes through a certification harness that executes artifacts against standard input contracts in an isolated runtime. The harness records an explicit verdict:

• CERTIFIED: The component executes against its specification and passes verification.
• PROVISIONAL: The component is repeatable, but correctness is not yet asserted.
• INCONCLUSIVE: The harness could not exercise the contract (a harness limit, not an artifact defect).
• FAILED: The component failed under execution.

Counts across the engineered catalog, the discovery vault, and our Crown Jewels are tracked separately and never summed. You can inspect how artifacts are evaluated on the live harness or submit your own codebase through the free repository evaluation.

What to run on Monday

Stop trusting manifest export lists as proof of component health. You can surface broken entries across your internal registry with a simple smoke-execution script in CI:

#!/usr/bin/env bash
set -euo pipefail

## Find all package entrypoints and attempt isolated dynamic imports
for pkg in packages/*; do
  [ -d "$pkg" ] || continue
  node -e "
    try {
      const mod = require('./${pkg}');
      if (Object.keys(mod).length === 0 && typeof mod !== 'function') {
        console.error('FAIL: ${pkg} exported an empty namespace');
        process.exit(1);
      }
      console.log('OK: ${pkg}');
    } catch (err) {
      console.error('CRASH: ${pkg} failed to initialize:', err.message);
      process.exit(1);
    }
  "
done