Hidden Assumptions in eslint
10 assumptions this code never checks · 4 critical · spanning Environment, Shape, Domain, Contract, Resource, Ordering, Scale, Temporal
Every codebase relies on things it never checks. Most of them are routine. CodeSea looked at eslint/eslint 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".
On Node.js builds without worker thread support or in environments where worker_threads is disabled, ESLint will crash with module import errors when attempting parallel processing
If a plugin is malformed (missing rules property or rules is not an object), rule lookup will silently fail or throw confusing property access errors instead of clear validation messages
If LATEST_ECMA_VERSION is updated without adding corresponding globals, ECMASCRIPT_GLOBALS will be undefined, causing rules that check global variables to fail or behave incorrectly
Show everything (7 more)
All Unicode utility functions handle the full Unicode character space correctly across different JavaScript engine implementations - no validation that the engine properly supports surrogate pairs, combining characters, or emoji modifiers
If this fails: On JavaScript engines with incomplete Unicode support or different Unicode versions, character classification functions may return incorrect results, causing rules to misidentify code constructs involving Unicode identifiers
lib/rules/utils/unicode/index.js:module.exports
The global Symbol registry remains consistent and the 'eslint.RuleTester.parser' symbol is unique - relies on Symbol.for() creating the same symbol across different module loads without checking for symbol collisions
If this fails: If another library or version of ESLint uses the same symbol key, rule tester could access the wrong parser implementation, leading to test failures or incorrect rule validation
lib/rule-tester/rule-tester.js:Symbol.for
Memory usage scales linearly with config array size and that large config arrays can be held in memory simultaneously - no memory usage checks or streaming for large configuration sets
If this fails: Projects with extremely large or deeply nested config arrays could exhaust available memory, especially when combined with other ESLint memory usage during parallel processing
lib/config/flat-config-array.js:ConfigArray
Config arrays are always assembled in the exact order: base config, original configs, user-defined configs, CLI-defined configs - the error index calculation depends on this precise ordering being maintained
If this fails: If config loading order changes or configs are inserted out of sequence, error reporting will show incorrect config indices, making it impossible for users to locate the actual problematic configuration
lib/config/flat-config-array.js:wrapConfigErrorWithDetails
Rule validation schemas remain stable once compiled and cached - the WeakMap cache never expires or invalidates cached validators even if rule definitions change
If this fails: If a rule's schema changes during runtime (e.g., through plugin hot-reloading), cached validators will continue using the old schema, causing incorrect validation results or missing new constraint violations
lib/config/config.js:validators WeakMap
The package.json file exists at the expected relative path and contains valid JSON with name and version properties - no existence or schema validation before accessing properties
If this fails: If package.json is missing, corrupted, or lacks name/version fields, the module will throw runtime errors during import, breaking any code that tries to load this package
packages/js/src/index.js:require('../package.json')
Test case error objects have a predictable shape with properties like message, line, column - the typedef shows the expected structure but no runtime validation ensures test cases conform to this shape
If this fails: Malformed test case objects with missing or wrong-typed properties will cause confusing test failures or incorrect test results instead of clear validation errors about test case structure
lib/rule-tester/rule-tester.js:TestCaseError
See the full structural analysis of eslint: the pipeline, data models, and system behavior that put these assumptions in context.
Full analysis of eslint/eslint →Compare eslint
Frequently Asked Questions
What does eslint assume that could break in production?
The one most likely to cause trouble: Worker threads are available and functional in the Node.js runtime - the code imports Worker from worker_threads and spawns worker processes for parallel linting without checking if worker threads are supported or enabled If this fails, On Node.js builds without worker thread support or in environments where worker_threads is disabled, ESLint will crash with module import errors when attempting parallel processing
How many hidden assumptions does eslint have?
CodeSea found 10 assumptions eslint relies on but never validates, 4 of them critical, spanning Environment, Shape, Domain, Contract, Resource, Ordering, Scale, Temporal. 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.