This is a bit of an older discussion but there is some useful information here https://discuss.flarum.org/d/6320-extension-developers-show-us-your-workflow
Debugging Flarum is not much different from debugging other PHP applications.
Knowing what might cause a given exception takes a bit of learning.
Extensions are so powerful they can affect all parts of the codebase. Knowing what features of the framework each extension you're working with is using is useful.
For example if you have an issue with routing but you are not registering any route, maybe you're simply hitting the wrong URL. Or if an error is triggered during a Flarum event that you're not interacting with, then it's likely related to another extension.
The PHP backtrace can be very long but usually has some useful information about which extension might be responsible.
Stopping code execution in various places with var_dump(); die(); calls is usually my preferred method of dealing with incomprehensible situations.
The increasing use of callables bound to the container via the Flarum PHP extenders is sadly not helping as the callable usually loose context and don't always provide much help in the backtrace. But disabling extensions or commenting extensions is usually enough to locate the infringing code and go back to dump calls.
Javascript is more difficult to troubleshoot because of the use of monkey-patching. The methods get encapsulated so much into each other, you need a browser with good dev tools to dig into the trace of such errors. I usually switch between Firefox and Chrome if one browser is not able to map the backtrace to the source code properly.
