Deadlocks

[guybedford]

Going through the design here with @jasnell, he brought up that being able to provide an error on deadlocks would be a preferable behaviour to actually deadlocking.

From a spec perspective, we could either let such a behaviour be a host-defined error, or specified here, which would be worth discussing further.

[jasnell]

My preference would be for specifying it here but could be convinced on the host-defined error path.

[jasnell]

Drawing this out a bit more...

My preference is for spec-defined detection and a spec-defined throw here, for a few reasons.

The deadlock scenario we're concerned about is where import.sync() is called for a module whose transitive dependency graph includes a module currently mid-evaluation. There are a few distinct scenarios worth walking through:

Scenario 1: Mutual import.sync — true deadlock

// a.mjs
export const b = import.sync('./b.mjs');
export const a = 'a';

// b.mjs
export const a = import.sync('./a.mjs');
export const b = 'b';

When a.mjs evaluates and hits import.sync('./b.mjs'), b.mjs begins evaluating synchronously on the same call stack. It then hits import.sync('./a.mjs'), but a.mjs is ~evaluating~ — its namespace cannot be produced because it hasn't finished executing. This is an unresolvable deadlock.

Scenario 2: import.sync into a static cycle — same problem

// a.mjs
import './b.mjs';
export const a = 'a';

// b.mjs
import './a.mjs';
const aSyncRef = import.sync('./a.mjs');
export const b = 'b';

Here the cycle is created by static imports, and import.sync references a module already ~evaluating~ as part of the same strongly connected component. The static cycle would work fine on its own via live bindings, but import.sync is asking for the complete namespace of a module that hasn't finished executing. Same fundamental problem — should throw.

Scenario 3: Dependency outside the target's graph is evaluating — no problem

// a.mjs
import './c.mjs';
export const a = 'a';

// b.mjs
export const b = 'b';

// c.mjs
const b = import.sync('./b.mjs');
export const c = 'c';

Here a.mjs may be ~evaluating~ when c.mjs calls import.sync('./b.mjs'), but b.mjs has no dependency on a.mjs. The target's dependency graph is clean. This should succeed — we only need to check the target's transitive dependency graph, not whether anything else in the realm is mid-evaluation.

Scenario 4: Async dependency in the graph — ~evaluating-async~

// a.mjs
const b = import.sync('./b.mjs');

// b.mjs
import './c.mjs';
export const b = 'b';

// c.mjs
await fetch('...');
export const c = 'c';

If c.mjs has started evaluation but is pending on TLA (~evaluating-async~), b.mjs can't complete synchronously either. This should also throw.

The relevant state is entirely spec-level. No host-specific information is needed to detect any of these cases. This means the detection can be fully specified, giving us deterministic, portable behavior across all hosts. Leaving it host-defined risks inconsistency.

It's worth contrasting this with how Node.js handles circular require() in CommonJS, where a partially-constructed module.exports object is returned. That approach avoids hangs but introduces silent partial initialization bugs. It think we all agree we should not repeat that mistake. A clear error is strictly better.

This check likely belongs in ReadyForSyncExecution. That already needs to walk the transitive dependency graph to check for [[HasTLA]]. Extending that same walk to also check for ~evaluating~ and ~evaluating-async~ status in the graph is straightforward and avoids duplicating traversal logic. If any module in the target's transitive dependency graph is in either of those states, the graph cannot complete synchronously, and we should throw.