Identify Vendor Code Before Rewriting the Bundle

A production bundle is rarely one codebase in one file.

It can contain first-party application logic, framework runtime, package code, copied utilities, transformed shaders, generated module loaders, polyfills, and code that began as a dependency but was patched locally before shipping.

Treating that mixture as one cleanup surface creates two opposite mistakes: rewriting vendor code as if it were authored locally, and preserving application code as if it belonged to a package.

Identification is not extraction

Finding evidence that a region resembles a known library is useful. It does not yet authorize replacing those bytes with a registry dependency.

The shipped region may be:

• a standard package release;
• a different version than the manifest suggests;
• tree-shaken to a subset;
• transformed by a plugin;
• bundled with another package;
• patched or forked;
• copied into first-party source;
• wrapped in a container whose boundaries are not obvious.

Identification answers “what might this be?” Safe externalization asks a stronger question: “can the candidate use this exact package surface without changing its consumers or behavior?”

Evidence comes from several directions

Useful vendor signals include:

• source-map paths and embedded package names;
• license banners and distinctive strings;
• module wrapper structure;
• package-specific exports and call shapes;
• runtime constructor names and version fields;
• source hashes or known release fingerprints;
• import and consumer patterns;
• exact versions observed at runtime;
• negative evidence showing where the match stops.

No one signal should silently dominate. A familiar function name is weak evidence. An exact source hash is stronger. A runtime version plus matching source regions and consumer shape is stronger still.

Exact pins protect donor-era behavior

When the evidence supports replacing a bundled region with a package dependency, version ranges can reintroduce uncertainty.

The candidate is trying to reproduce a particular deployed generation. Widening an observed exact version to a caret range allows a later install to select code that never existed in the donor.

The first maintainable handoff should preserve the donor-era pin where it is known. Dependency upgrades can happen later as normal engineering changes with their own tests and review.

Modified vendor code needs a different outcome

A package match may be mostly correct while a small region differs.

That difference can be a local bug fix, product integration, security patch, build transform, or false match. Replacing the entire region with a clean package can remove behavior the application depends on.

The honest outcomes are explicit:

• externalized to an exact package version;
• retained because the shipped code is modified;
• split into package code plus a first-party bridge;
• quarantined pending more evidence;
• left bundled because safe consumer closure is not proven.

“Recognized” should never be serialized as “safe to delete.”

Generated runtime is another ownership class

Bundler bootstrap code is not ordinary vendor code either. It owns module registration, chunk loading, public paths, and runtime glue. Removing it before the candidate has a replacement module graph can make otherwise valid source unreachable.

Recovery therefore separates package boundaries from container and runtime boundaries. A library may be understood while the wrapper around it still needs to remain until the candidate build owns loading.

Why this improves the final project

A measured dependency inventory helps engineers answer:

• Which dependencies can be maintained through ordinary package tooling?
• Which shipped modifications must remain visible?
• Which code is truly first-party and needs semantic recovery?
• Which versions reflect the deployment rather than a stale manifest?
• Which regions remain uncertain and should not be aggressively cleaned?

KodeBack treats vendor demixing as provenance work before it is source mutation. The goal is not the smallest source tree. It is a candidate whose ownership boundaries are clearer than the bundle’s—and whose substitutions are backed by evidence.