Hidden Assumptions in oxc
12 assumptions this code never checks · 3 critical · spanning Environment, Ordering, Shape, Resource, Temporal, Contract, Scale, Domain
Every codebase relies on things it never checks. Most of them are routine. CodeSea looked at oxc-project/oxc 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".
Silent failures when loading native modules on unsupported platforms, or crashes with cryptic 'module not found' errors that don't clearly indicate platform incompatibility
If steps are reordered or skipped, semantic information becomes stale, transformations operate on incorrect AST structure, and generated code contains wrong symbol references
Test runner crashes with file not found errors or produces incomplete conformance results when babel tests are missing or corrupted
Show everything (9 more)
The experimentalRawTransfer and experimentalLazy options are mutually exclusive - only one can be true at a time
If this fails: If both options are enabled, the function uses the first condition (experimentalRawTransfer) and ignores experimentalLazy, causing unexpected behavior when lazy deserialization was intended
napi/parser/src-js/index.js:parseSync
The 'ldd' command is available in PATH and execSync can successfully execute it to detect musl vs glibc
If this fails: Falls back to 'false' if ldd command fails, potentially loading wrong native bindings and causing crashes on musl-based Linux distributions like Alpine
napi/*/index.js:isMuslFromChildProcess
The source_text field remains valid and unchanged throughout the entire parsing/transformation pipeline lifetime
If this fails: If source text is modified after parsing but before error reporting, diagnostic messages show incorrect line/column positions or wrong source snippets
napi/playground/src/lib.rs:Oxc::source_text
The transformTestFilename function returns consistent results when called multiple times with the same filename input
If this fails: Test discovery becomes non-deterministic, causing tests to be included or excluded randomly between runs, making conformance results unreliable
apps/oxlint/conformance/src/index.ts:TestGroup::transformTestFilename
AST structures fit within JavaScript object size limits and don't exceed V8's maximum object property count (~16M properties)
If this fails: Large files with deeply nested ASTs cause out-of-memory errors or silent truncation when converting from Rust to JavaScript objects via NAPI
napi/playground/src/lib.rs:Oxc::ast
All TestGroup objects in the TEST_GROUPS array have valid submoduleName properties that correspond to actual directories in the submodules folder
If this fails: Conformance testing fails with path resolution errors when trying to locate test files for groups with invalid or mismatched submodule names
apps/oxlint/conformance/src/groups/index.ts:TEST_GROUPS
File extensions accurately indicate the language variant (.ts = TypeScript, .jsx = React, .vue = Vue) and parsing mode (module vs script)
If this fails: Files with non-standard extensions or content that doesn't match the extension get parsed with wrong syntax rules, leading to parse errors or incorrect AST structure
napi/playground/src/lib.rs:oxc_formatter::get_parse_options
If all platform-specific native binding attempts fail, the loadErrors array contains meaningful error messages that help diagnose the issue
If this fails: When no native bindings can be loaded, users get cryptic error messages that don't clearly indicate whether it's a platform issue, missing dependency, or corrupted installation
napi/*/index.js:loadErrors
Expected output files in Babel test fixtures contain syntactically valid JavaScript that can be parsed and compared against Oxc output
If this fails: Test comparison fails with parse errors when Babel's expected outputs contain invalid syntax or when file encoding doesn't match expectations
tasks/transform_conformance/src/lib.rs:TestCase
See the full structural analysis of oxc: the pipeline, data models, and system behavior that put these assumptions in context.
Full analysis of oxc-project/oxc →Frequently Asked Questions
What does oxc assume that could break in production?
The one most likely to cause trouble: Native NAPI bindings (.node files) exist for the current platform/architecture combination and are compatible with the runtime Node.js version If this fails, Silent failures when loading native modules on unsupported platforms, or crashes with cryptic 'module not found' errors that don't clearly indicate platform incompatibility
How many hidden assumptions does oxc have?
CodeSea found 12 assumptions oxc relies on but never validates, 3 of them critical, spanning Environment, Ordering, Shape, Resource, Temporal, Contract, Scale, Domain. 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.