What a Bundler Hides: App Code, Dependencies, and Glue

Open a modern production bundle and you are not looking at one codebase.

You are looking at a compressed mixture of many ownership classes:

• the application’s own logic;
• framework runtime;
• utility packages;
• UI libraries;
• loaders and addons;
• private or modified vendor code;
• duplicated package versions;
• generated wrappers;
• bundler module loaders;
• lazy-chunk registration;
• compatibility shims;
• inline assets and text;
• code introduced by the build rather than written by the application developer.

If a recovery workflow treats every byte as first-party source, it will waste enormous effort and introduce risk.

Why vendor confusion is expensive

A raw agent asked to “clean up this minified application” sees a large anonymous surface.

Without dependency evidence, it may:

• rename package internals as if they were app concepts;
• split vendor code into invented modules;
• spend tokens explaining a library that already exists on npm;
• replace a donor-era package with the latest incompatible release;
• externalize only part of a singleton family and create two runtimes;
• remove a wrapper the deployed application depends on;
• label modified vendor code as ordinary first-party logic;
• preserve megabytes of package code inside the final application without explaining why.

The issue is not merely readability. It is ownership and replacement policy.

Fingerprinting answers “what might this be?”

Dependency fingerprinting can use several evidence classes:

• package banners and license text;
• source-map paths and sourcesContent;
• public API names;
• constant tables;
• shader strings;
• error messages;
• known class and constructor shapes;
• export signatures;
• runtime identity;
• source text compared with published artifacts;
• release timelines;
• bundler and module-graph structure.

The strongest result may identify an exact package and version.

A weaker result may identify only a family.

Some regions remain ambiguous because the package was modified, private, partially inlined, tree-shaken, or mixed with first-party wrappers.

A trustworthy report preserves that distinction.

Demixing answers “which bytes belong to it?”

Knowing that a bundle contains a framework does not automatically tell us which span can be removed safely.

Demixing needs to reason about:

• bundler module boundaries;
• scope-hoisted ownership;
• shared helpers;
• aliases;
• first-party consumers;
• package families;
• closure and transitive dependencies;
• initialization order;
• duplicated singletons;
• side effects;
• import and export shape;
• whether a contiguous replacement region exists.

A package can be correctly identified while still being unsafe to externalize.

That is why attribution and mutation must remain separate steps.

Exact version matters

Replacing captured vendor code with “the same package” is not enough.

APIs change. Defaults change. Module formats change. Browser builds and ESM builds can expose different globals. Addons may assume one core singleton. A Three.js release, for example, can differ in color handling, loader behavior, shader details, or addon compatibility even when the high-level class names look familiar.

The deployed application already contains a version decision.

A recovery system should try to establish that donor-era identity rather than silently upgrading during recovery.

An upgrade may be valuable later. It is a different transaction with different evidence.

Public package, donor-vendored, private, or mixed

A useful dependency report should distinguish at least:

Exact public package

The shipped source or runtime matches a published artifact strongly enough to support an exact pin and replacement plan.

Donor-vendored package

The code appears package-derived but does not match a safe public replacement. It may be modified, bundled from a private source, or missing companion files. Retaining the captured authority can be safer than guessing.

Private or missing package

Imports, maps, or source paths identify a dependency that cannot be obtained from the public registry or supplied materials.

Mixed wrapper

First-party code and package code share a module or closure. The region may require a more careful split or remain retained.

Ambiguous

The evidence is insufficient. The correct output is not a confident package name; it is a bounded unresolved classification and a request for more evidence.

Singleton families need coordinated plans

Some packages cannot be externalized one file at a time.

A core runtime and its addons may share identity, global registries, symbols, caches, prototype expectations, or internal state. Replacing the core while leaving captured addons can create duplicate instances or incompatible object families.

A safe plan may need to move:

• core package;
• loaders;
• post-processing addons;
• framework renderer;
• helper libraries;
• first-party import sites;
• captured facades;
• runtime global assumptions;
• tests and parity states.

The unit of work is the family, not the first matching span.

Why build-green is still insufficient

A replacement can compile and still be wrong.

The candidate may import successfully but:

• create a second runtime instance;
• lose side effects;
• expose a different export shape;
• load a browser-incompatible package surface;
• change module-evaluation order;
• omit a raw asset;
• fail only after a specific user action;
• render differently without throwing an error.

Demixing therefore needs proof obligations after mutation:

• source and plan freshness;
• exact import rewrites;
• no retained consumer of removed ownership;
• module-load and export checks;
• project gates;
• runtime and visual evidence where relevant;
• rollback when the candidate regresses.

What should be deterministic

Several parts of this work can be repeatable:

• parsing the bundle;
• building the module graph;
• locating exact source-map paths;
• matching stable fingerprints;
• classifying known ownership evidence;
• enumerating consumers;
• planning exact import changes;
• applying a reviewed plan;
• running the required checks;
• recording a refusal.

Judgment may still be needed for:

• deciding whether a modified vendor should remain captured;
• choosing among several package candidates;
• interpreting a private wrapper;
• selecting the product policy for a live service;
• deciding whether a larger family transition is worth the risk.

The model should not have to rediscover the graph or write an unbounded patch to express that judgment.

The buyer-facing result

A KodeBack dependency and demix report should answer:

• What third-party code shipped?
• Which version evidence exists?
• Which code is first-party, vendor, mixed, or unresolved?
• Which packages can be externalized safely?
• Which regions must remain captured?
• Which exact consumers and contracts block replacement?
• Which dependencies remain live or missing?
• What did the candidate prove after the change?

That information matters even before full source recovery.

It can support modernization, supply-chain understanding, vendor takeover, and client-side exposure analysis.

A production bundle is not just unreadable source.

It is an ownership puzzle. Solve that puzzle before asking an agent to make everything look clean.