nx
Nx
GitHub
Nx
Workspace
GitHub
CI Pipeline Executions
Filtered
Runs
Demo
Insights
Compare tasks
Analytics
Sign in
Toggle sidebar
Overview
⌘K
Nx
Loading workspace stats
Loading workspace insights...
Statistics interval
7 days
30 days
Latest CI Pipeline Executions
Status
Fix filter
Filter
Fuzzy
Filter range
Sort by
Sort by
Start time
Sort ascending
Sort descending
Failed
36596
94ac920a fix(core): only flag the wasm runtime as a fallback when the native package is unresolvable Gating the warning on platform and arch alone produces a false positive. WebContainers and StackBlitz report linux/x64 and install @nx/nx-linux-x64-gnu normally, but dlopen fails there, so nx correctly runs WASM. Every StackBlitz boot printed a broken lockfile diagnosis that did not apply, and nx report called the runtime a fallback for the same reason. Gate both surfaces on the signature of the install this actually targets: the expected native package cannot be resolved at all. A package that resolves but will not load is left alone, as is NAPI_RS_FORCE_WASI and any platform outside the prebuilt matrix. Only a MODULE_NOT_FOUND counts as absent, so any other resolution error is treated as present and stays quiet. The expected package name and the resolvability probe are shared between the startup warning and nx report so the two cannot disagree. The report field is now a neutral native or wasm, and only appends (missing <package>) under that same predicate.
by Steven Nance
S
Failed
36596
Generating fix
→
2b9e69a0 fix(core): warn loudly when falling back to the WebAssembly runtime When the platform native binary is missing from node_modules, the generated native-bindings.js silently falls back to the bundled WASM runtime. That fallback always succeeds, so nx keeps running but the workspace context and hasher can spin at 100% CPU for hours with no output, which reads as a hang rather than a broken install. The one existing WASM warning lives behind the daemon-enabled check, and in CI the isCI/isDocker branch above it wins first, so it never fires in the environment where this actually bites. Warn on stderr as soon as IS_WASM is observed, naming the missing platform package and the lockfile cause behind it. The warning uses a synchronous fd write because a queued async write cannot drain once the process blocks in synchronous WASM work, and dedupes through NX_WASM_FALLBACK_WARNED so the processes nx spawns do not each repeat it. NX_ALLOW_WASM_FALLBACK=true silences it, and genuine WASM-only platforms stay quiet. Also surface the runtime in nx report so the fallback is visible when diagnosing after the fact.
by Steven Nance
S
Failed
36596
Fix applied
→
2b9e69a0 fix(core): warn loudly when falling back to the WebAssembly runtime When the platform native binary is missing from node_modules, the generated native-bindings.js silently falls back to the bundled WASM runtime. That fallback always succeeds, so nx keeps running but the workspace context and hasher can spin at 100% CPU for hours with no output, which reads as a hang rather than a broken install. The one existing WASM warning lives behind the daemon-enabled check, and in CI the isCI/isDocker branch above it wins first, so it never fires in the environment where this actually bites. Warn on stderr as soon as IS_WASM is observed, naming the missing platform package and the lockfile cause behind it. The warning uses a synchronous fd write because a queued async write cannot drain once the process blocks in synchronous WASM work, and dedupes through NX_WASM_FALLBACK_WARNED so the processes nx spawns do not each repeat it. NX_ALLOW_WASM_FALLBACK=true silences it, and genuine WASM-only platforms stay quiet. Also surface the runtime in nx report so the fallback is visible when diagnosing after the fact.
by Steven Nance
S
Previous
Next