Read on Twitter
It feels like all that I do now is fight with JavaScript tooling. Very little actual product work; just thrashing as hard as I can to stay in the same place. Maybe I should cut my losses and rebuild the entire application to render server-side and live with the UX degradation.
It turns out that the webpack watcher was working. The problem was that turning on the minifier increased the watcher's reaction time from 1.5 seconds to 26 seconds, and I didn't think to wait that long. My fault for not being more careful and patient when testing.
My frustration still stands. I need errors in user-entered code to not bubble up to onerror/unhandledrejection, and AFAICT that means inspecting the stack, which means that my error handling is sensitive to minification, which means minifying in dev to avoid dev/prod mismatch.
So, as usual, it's not any one tool; it's the system of tools. There's no way to scope error handling, leaving me to inspect stacks as strings to try to filter errors out. But that would require increasing my dev build turnaround time to 26 seconds, which is untenable.
(We're not actually doing this today for this reason. Instead, there's a hodgepodge of different error handling hacks. E.g., in user code, "Promise" is actually our ExecprogPromise, and our top-level unhandledrejection handler ignores any rejection coming from that class.)
