Hidden Assumptions in webpack
9 assumptions this code never checks · 3 critical · spanning Temporal, Ordering, Environment, Contract, Domain, Scale, Resource
Every codebase relies on things it never checks. Most of them are routine. CodeSea looked at webpack/webpack and picked out the few most likely to cause trouble. The full list is just below.
Most of what this code assumes is routine. These 3 are the ones most likely to cause trouble here. The rest are minor; they're under "Show everything".
If remote modules fail to initialize or are slow to respond, bootstrap.js will execute with incomplete shared module state, causing runtime errors when remote modules are accessed
If shared module initialization takes longer than the import resolution, bootstrap.js could execute before shared dependencies are available, causing module resolution failures
In environments where webpack's runtime hasn't properly initialized this global (like server-side rendering or custom module loading), accessing .usedExports throws ReferenceError
Show everything (6 more)
JSON files (a.json, b.json, c.json, e.json) will always parse successfully and return the expected JavaScript values without validation of JSON structure
If this fails: If JSON files contain malformed syntax or unexpected data types, require() calls will throw parse errors that aren't caught, breaking the test suite
test/cases/json/data/index.js:require
The JSON test data represents all valid JSON types that webpack's JSON loader should handle, but doesn't validate edge cases like circular references, extremely deep nesting, or special numeric values
If this fails: Production code using JSON loader with complex real-world JSON could fail in ways not caught by these tests - stack overflow on deep objects, precision loss on large numbers
test/cases/json/data/index.js:data_structure
__filename is available and points to the current module file path in all JavaScript environments where webpack bundles run
If this fails: In environments without Node.js globals (like pure browser environments or web workers), __filename is undefined, causing the loader test to fail with 'undefined' concatenation
test/cases/loaders/utils/index.js:__filename
The './loader!' prefix syntax will always resolve to a valid loader that returns an object with request1 and request2 properties of type string
If this fails: If the loader is missing, malformed, or returns unexpected format, the test fails with property access errors or type mismatches that don't clearly indicate the loader system failure
test/cases/loaders/utils/index.js:loader_format
Re-exporting all exports from './a' and './b' modules assumes these modules don't have naming conflicts and don't export an excessive number of bindings
If this fails: If modules a and b export the same named binding, one silently overwrites the other. If they export thousands of bindings, bundle size and initialization time degrade significantly
test/cases/chunks/statical-dynamic-import-destructuring/lib/index.js:export_reexport
Network conditions allow for reliable loading of remote module chunks with reasonable latency during the async boundary wait
If this fails: In poor network conditions or high-latency environments, the import('./bootstrap') could timeout or fail, leaving the application in a broken state with no fallback mechanism
examples/module-federation/src/index.js:async_loading
See the full structural analysis of webpack: the pipeline, data models, and system behavior that put these assumptions in context.
Full analysis of webpack/webpack →Frequently Asked Questions
What does webpack assume that could break in production?
The one most likely to cause trouble: Module federation remotes are initialized and ready to provide shared modules before bootstrap.js executes, with no timeout or retry mechanism If this fails, If remote modules fail to initialize or are slow to respond, bootstrap.js will execute with incomplete shared module state, causing runtime errors when remote modules are accessed
How many hidden assumptions does webpack have?
CodeSea found 9 assumptions webpack relies on but never validates, 3 of them critical, spanning Temporal, Ordering, Environment, Contract, Domain, Scale, Resource. Most are routine — the analysis flags the two or three most likely to actually bite.
What is a hidden assumption?
Something the code depends on but never checks: a data shape, an ordering, an environment condition, a scale limit, or a contract with another service. It holds until the world it runs in changes, then fails silently.