I Built a Reactive Compiler for JavaScript — Here's Where It Broke
In Part 1, I showed you the vision: a framework where you write let count = signal(0), const doubled = count * 2, and the compiler handles the rest. Two imports, zero ceremony, Solid-level performa...

Source: DEV Community
In Part 1, I showed you the vision: a framework where you write let count = signal(0), const doubled = count * 2, and the compiler handles the rest. Two imports, zero ceremony, Solid-level performance with React-like syntax. It was elegant. It was exciting. And it immediately raised a question that nearly broke my brain. The question that changes everything Consider this innocent-looking code: let count = signal(0); // Case 1: Returning from a composable function useCounter() { return { count }; } // Case 2: Logging console.log(count); // Case 3: Passing to a child component <Display value={count} /> // Case 4: Arithmetic const doubled = count * 2; In all four cases, count appears as a plain variable. But the compiler needs to do completely different things depending on where it appears: Case 1 (return): Should pass the signal object — so the call site can still subscribe to changes Case 2 (log): Should pass the current value — console.log doesn't know what a signal is Case 3 (JS