Core Concepts of Modern Bundling

The frontend build landscape has undergone a fundamental architectural shift over the past five years. Legacy bundlers, which relied on monolithic JavaScript parsers and synchronous dependency resolution, have been superseded by a generation of tooling that prioritizes deterministic outputs, sub-second hot module replacement (HMR), and native ESM-first development servers. Modern bundlers like Vite, Rollup, and esbuild decouple the developer experience from production optimization, leveraging Rust- and Go-native compilers to achieve 10–100x speed improvements in cold starts and incremental builds. This overview establishes the foundational mechanics of asset compilation, mapping the evolution from Webpack-era paradigms to contemporary, plugin-driven architectures, and links out to the deeper guides on each mechanism. For frontend engineers, tooling developers, and framework maintainers, understanding these core concepts is the precondition for designing scalable, debuggable, high-performance build pipelines.

The reason this shift happened is economic, not aesthetic. A Webpack build on a large single-page application could take 30–90 seconds cold and several seconds per incremental edit, because every module — application code, node_modules, polyfills — was parsed, transformed, and linked in a single JavaScript process before the browser saw anything. That cost scaled linearly with project size, so the larger the codebase the slower the feedback loop, which is exactly backwards from what a growing team needs. The insight that unlocked the current generation is that development and production have opposite requirements: in development you want the smallest possible amount of work per keystroke and you do not care about final bundle size, whereas in production you want the smallest, most aggressively optimized artifact and you do not care how long the build takes. Conflating the two — bundling the whole graph up front just to serve it in dev — is the original sin the current tooling exists to correct, which is why Vite serves unbundled ESM in dev and only invokes a real bundler for vite build.

Getting the model wrong has concrete failure modes rather than vague slowness, and naming them up front is the point of this overview. A resolution misconfiguration surfaces as a module that imports cleanly in dev and throws undefined is not a function in the production bundle. A tree-shaking failure surfaces as a 400 KB charting library shipped to a page that never renders a chart. A chunking mistake surfaces as a five-request waterfall on the critical path, or as the framework core duplicated into every route chunk. A source-map gap surfaces the first time a production exception lands as t is not a function at column 41,209 of a single minified line. Each of the sections below maps one stage of the pipeline to the specific class of bug it prevents, and each links to a deeper guide that carries the mechanism further than an overview can.

Every modern bundler runs the same logical pipeline regardless of which language it is written in: it reads one or more entry points, resolves their imports into a module graph, parses each module into an AST, transforms that AST (TypeScript stripping, JSX, macros), prunes the dead branches with tree-shaking, and finally emits hashed chunks plus a manifest and source maps. The differences between Vite, Rollup, esbuild, and Turbopack are differences of emphasis inside this pipeline — how deep the analysis goes, how much is parallelized, and whether the work happens up front or on demand. The diagram below is the mental model the rest of this site builds on.

Module Systems and Resolution Strategies

At the heart of any modern bundler lies the module resolution engine, which constructs a directed graph from entry points to leaf dependencies. Contemporary tooling has moved beyond naive node_modules traversal to adopt standardized resolution aligned with the Node.js package.json exports and imports fields. Static import statements are analyzed at parse time to establish strict dependency boundaries, while dynamic import() expressions trigger lazy evaluation and a new chunk boundary.

Modern resolution must account for dual-package hazards, conditional exports ("development", "production", "browser"), and TypeScript path mapping ("paths" in tsconfig.json). The transition from CommonJS to ECMAScript Modules introduces real interoperability friction, particularly around synchronous require() calls, dynamic module.exports mutation, and top-level await semantics.

How resolution runs under the hood

Resolution is a depth-first walk that starts at each entry and, for every import specifier, answers one question: what absolute file on disk (or virtual module) does this string point to? A bare specifier like react triggers the Node algorithm — walk up the node_modules directories, read the package’s package.json, and consult the exports field to pick a target subpath. A relative specifier like ./utils is resolved against the importer’s directory, then extension-probed (.ts, .tsx, .js, .mjs, index files) in a configured order. The resolver memoizes every specifier-to-file decision because the same dependency is imported from dozens of call sites, and a cache miss means another stat syscall storm across the filesystem. This is why a cold build with an empty resolver cache is dramatically slower than a warm one, and why an over-broad resolve.extensions list that probes six extensions per import measurably slows a large graph.

The exports field is the part that most often goes wrong, because it is a firewall rather than a hint: once a package declares exports, any subpath not listed is unreachable, and import 'pkg/internal/thing' fails even though the file physically exists on disk. Conditional keys are matched top to bottom, so order is significant — a "require" condition placed above "import" hands a CJS build to an ESM consumer. The canonical dual-package hazard is a library that ships both an ESM and a CJS build without a shared state module: the bundler loads the ESM copy for a static import and the CJS copy for a transitive require, and you end up with two instances of what should be one singleton, two module-level caches, and instanceof checks that silently return false across the boundary.

// package.json — an exports map that avoids the dual-package hazard
// Node 18+, resolved identically by Vite, Rollup, and esbuild
{
  "name": "@acme/widgets",
  "type": "module",
  "exports": {
    ".": {
      "types": "./dist/index.d.ts",
      "import": "./dist/index.js",   // ESM consumers get the ESM build
      "require": "./dist/index.cjs"  // CJS consumers share state via one core
    },
    "./package.json": "./package.json"
  },
  "sideEffects": false
}

Working through understanding ESM versus CommonJS in modern bundlers makes it clear why graph traversal needs AST-level interop shims that wrap CJS without destroying static analyzability — the exact mechanism behind the dreaded "X is not exported by Y" error when a tool guesses a CJS module’s named exports wrong. Framework maintainers lean on standardized plugin hooks (Rollup’s resolveId, load, transform) to intercept resolution and inject virtual modules, keeping builds deterministic across heterogeneous ecosystems. The exact version-to-version behavior of these resolution algorithms — which Node releases honor which exports conditions, and where Rollup 3 and Rollup 4 diverge — is tracked in the bundler version compatibility reference.

One resolution edge case deserves its own note because it routinely wastes hours: TypeScript’s paths aliases are a compile-time convenience that the bundler does not automatically honor. tsc rewrites @app/* during type-checking, but Vite, Rollup, and esbuild each need the alias re-declared in their own config (resolve.alias, @rollup/plugin-alias, or esbuild’s alias map), or the build resolves @app/foo as a bare node_modules specifier and fails with a module-not-found that the editor never surfaced. The symptom is a green type-check and a red build, which reads as a bundler bug but is a configuration gap. Confirm the alias is wired into the bundler, not just tsconfig.json, by running the actual production build in CI rather than trusting the type-checker’s success — the two resolve modules through entirely separate code paths.

Optimization and Dead Code Elimination

Bundle size correlates directly with network latency, parse time, and memory overhead. Modern bundlers use aggressive static analysis to eliminate dead code through tree-shaking, pruning unused exports and unreachable execution paths from the final artifact. Effective tree-shaking depends on pure, side-effect-free module boundaries: bundlers read the "sideEffects" flag in package.json and honor /*#__PURE__*/ annotations to safely discard unused function calls, class instantiations, and IIFEs.

The trade-off between aggressive minification and analyzability is a core architectural decision. Tools like esbuild reach remarkable compression ratios via parallelized AST traversal, but deliberately omit deep semantic analysis to preserve sub-100ms builds. Rollup 4 and Vite’s production pipeline integrate more thorough scope hoisting and control-flow analysis, reducing global collisions and improving runtime execution speed. Getting tree-shaking mechanics and dead-code elimination right demands strict ESM export patterns and disciplined handling of barrel files (index.ts), which routinely introduce implicit side effects that defeat static elimination — re-exporting a module with a top-level console.log or a polyfill import is enough to retain the whole subtree. Benchmark data consistently shows that correctly configured tree-shaking cuts initial JavaScript payloads by 30–60% in component-heavy frameworks.

What actually makes an export shakeable

Tree-shaking is not a size heuristic; it is a reachability analysis over the ESM binding graph. The bundler marks every export reached from an entry as live, then repeats transitively until the marked set stops growing; anything left unmarked is dead and elided. Three things defeat this analysis, and all three are common. The first is CommonJS: module.exports is a single runtime object whose shape is only known when the code executes, so a require()d module is imported whole — there are no statically separable named bindings to drop. The second is top-level side effects: any statement that runs at import time (a console.log, a prototype patch, a window.foo = ..., a self-registering plugin) makes the module impure, and unless sideEffects says otherwise the bundler must retain the entire module to preserve that effect. The third is the barrel file: export * from './everything' forces the bundler to pull the whole re-export surface into the graph before it can prove which leaves are unused, and if any single leaf is impure the pruning stalls there and drags its neighbors in with it.

The sideEffects field is a promise you make to the bundler, and a wrong promise is worse than none. "sideEffects": false tells the bundler that importing any file in the package purely for its effects is meaningless, so it may drop any module whose bindings go unused. If that is a lie — you have a CSS import or a polyfill that must run for its effect — the bundler helpfully deletes it, and your styles vanish in production while dev, which never tree-shakes, looks fine. The precise fix is a file allowlist that names exactly the modules whose side effects matter:

// package.json — keep CSS and polyfills, shake everything else
// honored by Rollup 4, Vite, and Webpack 5
{
  "sideEffects": ["*.css", "./src/polyfills.ts"]
}

Confirm the outcome the only way that is trustworthy: build for production, open the bundle in a visualizer, and search for a symbol you know should be gone. If it is present, the analysis failed upstream — almost always a barrel file or a mislabeled side effect — rather than the bundler being lazy. Reading the visualizer is diagnostic, not decorative: it is the difference between believing tree-shaking worked and knowing which module defeated it.

Runtime Performance and Chunk Management

Delivering optimized code to the browser is more than compression; it requires strategic partitioning of the dependency graph. Modern chunk management isolates vendor dependencies, hoists shared modules, and aligns code boundaries with application routes. By leveraging dynamic imports, the bundler emits discrete chunks fetched on demand, improving First Contentful Paint (FCP) and Time to Interactive (TTI).

Effective chunking must account for HTTP/2 multiplexing, which favors smaller parallel requests, while balancing the overhead of extra round-trips. Long-term caching is enforced through content-based hashing ([hash] / [contenthash]), so unchanged vendor libraries stay cached across deployments.

Network-waterfall optimization further depends on <link rel="modulepreload"> hints and intelligent chunk grouping. When architecting code splitting strategies for large applications, engineers configure manual chunking directives to prevent framework-core duplication, isolate heavy third-party libraries (charting, PDF rendering), and enforce route-level boundaries that track user navigation. Misconfigured splitting frequently produces waterfall bottlenecks, where critical-path execution is blocked behind a deferred vendor payload, or the opposite failure — the same module duplicated across five chunks because Rollup’s manualChunks and the default heuristics disagreed.

How content hashing keeps caches warm

The hash in vendor.[hash].js is computed from the chunk’s final content, which is what makes long-term caching work: if react and react-dom do not change between two deploys, the vendor chunk’s bytes are identical, its hash is identical, and every returning user’s browser serves it from cache instead of the network. The failure mode is hash instability — a chunk whose hash changes on every build even though its source did not. The usual causes are a module-ID scheme that is index-based rather than content-based (so inserting one file renumbers everything downstream and rewrites every ID), or a chunk whose hash embeds the hash of an imported chunk that just changed, which cascades. Rollup 4 and Vite default to deterministic, content-derived IDs, but a custom manualChunks function that groups modules by a mutable criterion — an array index, a build timestamp — reintroduces the instability by hand.

Chunk boundaries are a genuine trade-off, not a free win. Every extra chunk is another request, another set of response headers, and another edge in the module-preload graph; under HTTP/2 the marginal request is cheap but not free, and under HTTP/1.1 it is expensive. Split too coarsely and one edit to any route invalidates a megabyte of shared cache for every user; split too finely and the browser opens twenty connections to paint one screen. The workable middle is a stable vendor chunk for dependencies that change on their own release cadence, a shared chunk for modules imported by three or more routes, and per-route lazy chunks behind dynamic import(). Encode that intent explicitly rather than trusting the default heuristic to guess it:

// vite.config.ts — explicit chunking for stable vendor caching
// Vite 6.x, Rollup 4 output options
export default {
  build: {
    rollupOptions: {
      output: {
        manualChunks(id) {
          // React and its runtime rarely change → one stable, cacheable chunk
          if (id.includes('node_modules/react')) return 'react-vendor';
          // Heavy, route-specific libraries stay out of the common path
          if (id.includes('node_modules/echarts')) return 'charts';
          // Everything else from node_modules → a general vendor chunk
          if (id.includes('node_modules')) return 'vendor';
        },
      },
    },
  },
};

Verify the split did what you intended by reading the build’s chunk report rather than assuming: the framework core must appear in exactly one chunk, no route chunk should re-bundle a shared dependency, and the vendor chunk’s hash should stay constant across a build where you changed only application code. If the vendor hash moves on an app-only edit, a route is leaking an import into the vendor group and the caching benefit is already gone — the browser will re-download the vendor chunk on the next deploy for no reason.

Distributed Architecture and Micro-Frontends

Enterprise-scale applications frequently require independent deployment cycles, team autonomy, and stack heterogeneity. Distributed build architectures address these constraints through shared dependency graphs, runtime module loading, and cross-origin asset resolution. Rather than compiling a monolithic bundle, modern tooling lets independent teams publish self-contained micro-applications composed at runtime or build time.

The implications of module federation and micro-frontend architectures extend far beyond iframe embedding. Runtime module sharing requires strict version pinning, dependency reconciliation, and contract enforcement to prevent duplicate framework instances and state collisions — the canonical symptom being two React copies producing Invalid hook call at runtime.

Modern implementations use native ESM import maps, SystemJS registries, or the Webpack 5 / Vite federation plugins to expose remote entry points. Cross-origin resolution adds complexity around CORS policy, service-worker caching boundaries, and security headers. Successful deployments mandate centralized dependency governance, resolving shared singletons (React, Vue, the state library) at the host level while keeping component scopes isolated.

The singleton contract in practice

Federation’s hardest problem is not loading remote code; it is agreeing on shared dependencies without shipping them three times. Each remote is built independently, so each one’s graph contains React unless you tell the build to treat React as shared and externalize it. The shared configuration declares which packages are resolved from a common runtime scope, whether a version mismatch is tolerated or fatal, and whether the package is a strict singleton. Marking React singleton: true means the first remote to load wins and everyone else uses that instance; omitting it means each remote may instantiate its own, which is precisely how you get two React copies, two dispatcher registries, and Invalid hook call the moment a shared component renders. requiredVersion turns a silent version drift into a loud, debuggable warning at load time rather than a corrupted render three interactions later.

// module-federation shared config — one React across host and remotes
// @module-federation/vite or webpack 5 ModuleFederationPlugin
shared: {
  react:       { singleton: true, requiredVersion: '^18.2.0' },
  'react-dom': { singleton: true, requiredVersion: '^18.2.0' },
}

The operational cost that teams underestimate is version lockstep: a strict shared singleton means the host and every remote must agree on a compatible major of the shared library, so a React 18-to-19 upgrade is no longer one team’s decision but a coordinated migration across every remote that shares it. That coupling is the price of a single runtime instance, and it is usually worth paying, but it must be an explicit governance decision made up front rather than a constraint discovered at runtime when a remote that upgraded early takes the whole composed application down.

Source Maps and Production Observability

The gap between local development velocity and production debugging fidelity is bridged by robust HMR protocols, source-map generation, and error-tracking integration. Modern dev servers use native ESM imports to skip full-page reloads, transmitting only changed module deltas over a WebSocket and achieving sub-50ms update cycles regardless of project scale.

In production, observability hinges on accurate source maps. They can be embedded (inline), externalized, hidden (emitted but not referenced from the bundle), or omitted entirely — each with distinct performance and security trade-offs. Hidden maps with sourcesContent give monitoring platforms exact line/column mapping without exposing source to anyone who opens devtools.

How a source map turns a minified trace back into source

A source map is a JSON file in the Source Map v3 format whose mappings field is a Base64 VLQ-encoded table relating every generated line and column back to an original file, line, column, and symbol name. The browser and error trackers read it lazily: nothing is deobfuscated until something asks for the original position of a generated coordinate. That is why the map’s presence costs nothing at runtime for users — it is fetched only when devtools open, or never at all in the hidden strategy where only your tracker holds a copy. The sourcesContent field optionally inlines the original source text into the map itself, which is what lets a tracker show the offending line even though it never had access to your repository; drop sourcesContent and the tracker can name the file and line but cannot render the surrounding code.

The upload pipeline is where this usually breaks. For the tracker to match a production stack trace to the right map, three identifiers must line up: the release version tagged in the running app, the same release tag on the uploaded map bundle, and the debug_id (or sourceMappingURL) that ties a specific minified file to its specific map. A mismatch — uploading maps from a build that is not the one you deployed, or forgetting to tag the release — produces the maddening failure where the tracker has maps and has traces but resolves them to the wrong lines, which is more misleading than having no maps at all. Confirm the loop end to end by throwing a deliberate error from a known line in a staging release and checking the tracker resolves it to that exact line before trusting it in production.

The full decision tree — sourcemap: 'hidden' in Vite, release tagging, and the upload pipeline that lets Sentry or Datadog deobfuscate a minified V8 stack trace — is covered in source maps and production debugging. Teams that skip this end up triaging t is not a function against column 41,209 of a single minified line; teams that wire it up get the original file, function, and line back in their error tracker.

Decision Matrix: Vite vs Rollup vs esbuild vs Turbopack

There is no universally correct bundler; the right answer is a function of what you are shipping. Application teams optimize for dev-server feedback and zero-config defaults; library authors optimize for output quality and format flexibility; monorepo platform teams optimize for incremental rebuild and cache reuse. The matrix below is the short version of those trade-offs.

The cross-cutting rule: use Vite when you are building an application and want the dev loop, Rollup (directly) when you are publishing a package and need UMD/CJS plus the deepest tree-shaking, esbuild as a transform engine or for internal tooling where a sub-second build outweighs a few extra kilobytes, and Turbopack when you are committed to Next.js and want its incremental compiler. Note that these lines are blurring: Vite is migrating its production bundler from Rollup to Rolldown, and esbuild already sits inside Vite as the dependency pre-bundler. Pin the exact versions you depend on — the per-version Node requirements and known conflicts live in the bundler version compatibility reference.

A more durable way to read the matrix is by the one axis each tool refuses to compromise on, because that is what predicts where it breaks. esbuild refuses to give up single-pass speed, so it accepts weaker tree-shaking and a deliberately small plugin surface — correct for a CLI or a dependency pre-bundle step, wrong as the final optimizer for a size-sensitive public bundle. Rollup refuses to give up output quality and format flexibility, so it accepts having no dev server of its own — correct for a published package, needlessly heavy for iterating on an app. Vite refuses to give up the instant dev loop, so it runs two engines (esbuild in dev, Rollup or Rolldown in production) and accepts the small risk that the two disagree about an edge case — correct for applications, and the structural reason a dev-only bug can vanish in the production build and vice versa. Turbopack refuses to decouple from Next.js, so it is hard to beat inside that framework and unavailable outside it. When someone proposes switching bundlers, the question is not which one wins a synthetic benchmark but which axis your project genuinely cannot compromise on.

Performance and Observability

Build performance is measurable, and you should measure it rather than trust vibes. The three numbers that matter are cold-start time (first build with an empty cache), warm incremental rebuild time (the inner dev loop), and production bundle size (gzipped, per route). Cold start is where Go and Rust toolchains win decisively — esbuild and Turbopack parse and transform in parallel native code, skipping the JavaScript parse-and-JIT tax that dominated Webpack builds. Warm rebuilds are where persistent caching matters: esbuild’s context() watch mode and Turbopack’s function-level cache reuse prior work so only the touched module subtree recompiles.

On the production side, wire bundle-size auditing into CI with rollup-plugin-visualizer or a size-budget check that fails the build when a route’s gzipped payload regresses past a threshold. Pair that with the source-map upload pipeline so the error tracker can map production stack traces back to source. The observability stack is only credible when both halves are present: size budgets catch the regression before users do, and source maps explain the runtime exception after they hit it. Lockfile validation and content-hash-aware artifact caching keep the builds deterministic across CI runners so the numbers you measure are reproducible.

Make the size budget a hard gate rather than a dashboard nobody reads. A budget that only warns is a budget that regresses one kilobyte per pull request until the page is twice its target and no single change looks guilty of the drift. Fail the build instead:

// vite.config.ts — surface an advisory limit, then enforce a hard gate in CI
// Vite 6.x; chunkSizeWarningLimit only logs, so it is not the enforcement point
import { defineConfig } from 'vite';

export default defineConfig({
  build: {
    chunkSizeWarningLimit: 250, // KB, pre-gzip — advisory warning in the log only
  },
});

The advisory limit above only writes to the log; for an enforced gate, run a size-limit step as a separate CI job that reads the gzipped byte count of each named chunk and exits non-zero past the threshold, so the pull request is blocked rather than merely annotated. Store the previous build’s sizes as an artifact and diff against them, because the number that actually matters is the delta a change introduces, not the absolute size a reviewer has no baseline to judge. The three build numbers — cold start, warm rebuild, per-route gzipped size — should be printed by CI on every run so a regression is visible in the pull request that caused it, not discovered a month later in a performance audit when the guilty commit is buried.

Future Trajectory

The bundling ecosystem is converging on native, compiled toolchains that bypass JavaScript parsing bottlenecks entirely. Rust-native bundlers — Rolldown (the Rollup-compatible bundler that will become Vite’s production engine) and Rspack (a Webpack-API-compatible Rust bundler) — are collapsing the historical gap between esbuild’s speed and Rollup’s output quality. Underneath them, Oxc provides a Rust-native parser, resolver, and linter, and Lightning CSS handles CSS at the same tier, so the entire toolchain trends toward a single fast native core with JavaScript only at the plugin edges.

The migration risk in this convergence is real but bounded, and it is worth naming precisely so it is treated as neither trivial nor terrifying. Rolldown aims for Rollup config and plugin compatibility, but aims is not is: a plugin that reaches into Rollup internals, depends on exact hook ordering, or parses the AST with a JavaScript library rather than the shared native parser is exactly where a swap can break. The defensive posture is to keep custom build logic expressed through the documented plugin hooks (resolveId, load, transform, renderChunk) and out of undocumented internals, so the engine underneath can be replaced without rewriting your integration. Oxc’s parser being shared across the linter, resolver, and bundler is the structural reason this convergence sticks — one AST implementation instead of four means a syntax feature is supported everywhere at once, and it is the same reason a bug in that core is felt everywhere at once. Treat a bundler-engine upgrade as its own change set with a bundle diff and a full CI pass, never as a silent minor-version bump.

In parallel, native browser primitives are maturing. Standardized Import Maps let the browser resolve bare specifiers without a build step, reducing the need for client-side shims and underpinning buildless micro-frontend composition. Build-time compilation continues to absorb runtime cost — React Server Components and Vue SFC compilation push work to the build so the client ships less. The practical takeaway: the abstractions in this overview (resolution, transform, tree-shaking, chunking, source maps) are stable, but the engines implementing them are being rewritten in Rust. Code against the standards — ESM, exports maps, Import Maps, source-map v3 — and the engine swap underneath stays a non-event.

Implementation Checklist

Before a build pipeline is production-ready, confirm each of the following:

• Module hygiene: ship ESM with an explicit package.json exports map; set "type": "module" and moduleResolution: "bundler" in tsconfig.json.
• Tree-shaking: declare "sideEffects": false (or an exact file list) and verify with a bundle visualizer that dead exports are actually dropped; audit barrel files for hidden side effects.
• Code splitting: define route-level dynamic-import boundaries and explicit manualChunks for heavy vendors; confirm there is no duplicated framework core across chunks.
• Federation (if applicable): pin shared singletons at the host and verify a single framework instance at runtime.
• Source maps: emit hidden maps in production and upload them to your error tracker with a release tag; confirm a deobfuscated stack trace end to end.
• CI gates: validate the lockfile, enforce a per-route gzipped size budget, and cache build artifacts by content hash for reproducibility.
• Version pinning: pin bundler and Node versions against the compatibility reference; treat major bundler upgrades as their own change with a bundle diff.

Treat this list as a gate, not a wish list: each item corresponds to a production incident that has happened to someone and maps back to a section above. Module hygiene prevents the resolution failure that only appears in the production bundle; the tree-shaking check prevents the dead library shipped to every user; the splitting check prevents the framework core duplicated across routes; the federation check prevents the duplicate-React hook crash; the source-map step prevents the unreadable production trace; the CI gates prevent the silent size regression and the non-reproducible build; and version pinning prevents the upgrade that changes output behavior without anyone deciding it should. A pipeline that passes all seven is not merely fast — it is debuggable under load, which is the property that actually matters at three in the morning when a release is on fire.

Related

• Code Splitting Strategies for Large Applications — route- and vendor-level chunk boundaries, manualChunks, and avoiding waterfall bottlenecks.
• Module Federation and Micro-Frontend Architectures — runtime module sharing, singleton governance, and remote entry points.
• Tree-Shaking Mechanics and Dead Code Elimination — sideEffects, /*#__PURE__*/, and barrel-file pitfalls.
• Understanding ESM vs CommonJS in Modern Bundlers — interop shims, dual-package hazards, and named-export resolution.
• Source Maps and Production Debugging — map types, hidden source maps, and uploading to Sentry for deobfuscated traces.
• Bundle Analysis and Size Budgeting — attributing every byte, finding duplicates, and enforcing CI size budgets.
• Bundler Version Compatibility Reference — tool-to-Node version pinning and known cross-version conflicts.