The issue is "when dev engine is in the process of generating hmr update, a new file change will cause the nodejs hang during the second hmr update generating"

In short, the hang is caused by deadlock.

## Details

Rolldown stores the client information into `client` variable using `DashMap`, which is basically equivalent to `Mutex<HashMap>`.

During the process of generating hmr update

https://github.com/rolldown/rolldown/blob/5ef49ad615cfef1a9ebc97368546e1b9adbaf48d/crates/rolldown_dev/src/bundling_task.rs#L140

this line of code is equivalent to `client.lock()`, will means the lock of `client` will be hold during the whole generating process.

The first hmr update is generated successfully and is sent to vite to trigger the hmr process.

The browser loads the hmr patch and and sends message to vite node to register the new loaded module via code

https://github.com/rolldown/rolldown/blob/0ce4a17c5ae1a95e331f8d38c5230742b09d1fd3/crates/rolldown_binding/src/binding_dev_engine.rs#L182-L184

nodejs calls `register_modules`

https://github.com/rolldown/rolldown/blob/0ce4a17c5ae1a95e331f8d38c5230742b09d1fd3/crates/rolldown_binding/src/binding_dev_engine.rs#L183

This line of is also equivalent to `client.lock()`.

In the meantime, dev engine is in the second hmr update generation, which holds the client lock already.

So nodejs needs to wait for this lock to get free, and this wait is a **SYNCHRONOUS** wait. The nodejs itself doesn't have chance to resolve pending promises anymore(like resolving a timeout timer), while the hmr generating is awaiting js `transform` hook to be finished.

All these things together cause a deadlock situation.

---

If we have #7287 in the first place, it will be much easier to locate the problem, becuase we could easily find out which function is the last called function from `binding.js`​.

---

# Visual Explanation of the Deadlock

### The Circular Dependency

```
    ┌──────────────────────────────────────────────────────────┐
    │                                                          │
    ▼                                                          │
┌────────────┐         ┌────────────┐         ┌────────────┐   │
│  Task 2    │ awaits  │  Node.js   │  waits  │   Lock     │   │
│  (Rust)    │────────►│  transform │────────►│ (held by   │───┘
│            │         │  hook      │  SYNC   │  Task 2)   │
└────────────┘         └────────────┘         └────────────┘
      │                      ▲
      │                      │
      │    register_modules  │
      │    called by browser │
      │    (from Task 1's    │
      │     HMR patch)       │
      └──────────────────────┘
```

### Sequence of Events

```
1. Task 1: Generate HMR #1 → Send to browser → Complete ✓
2. File changes again → Task 2 starts
3. Task 2: Acquire clients lock
4. Task 2: Call JS transform hook (await)
5. Browser: Receives HMR #1, loads patch, calls register_modules
6. Node.js: register_modules tries to acquire lock (SYNC)
7. Node.js: BLOCKED waiting for lock (Task 2 has it)
8. Task 2: Waiting for JS promise to resolve
9. Node.js: Can't process promises (event loop blocked)
10. DEADLOCK!
```

### The Fix

Making `register_modules` async allows Node.js to **yield control** when waiting for the lock, keeping the event loop alive so it can resolve the transform hook promise.

| Before (sync) | After (async) |
|---------------|---------------|
| Node.js **blocks entirely** waiting for lock | Node.js **yields** control back to event loop |
| Event loop frozen, can't process callbacks | Event loop continues, can process transform callback |
| **DEADLOCK** | **Works correctly** |

…ode-group-logo

docs: update favicon and custom code group logo