Yes; this is a big part of my day job.
First, understand that you are most likely dealing with a dart2js bug, not a bug in your code. Your immediate goal is to work around the problem. The end goal, though, is to construct a small test case that you can file on dartbug.com.
Checked mode is your friend
If you are really lucky, enabling checked mode will throw an assertion that will point to the problem. If not, you'll need to dig into the JS.
Using pub serve
or pub build --mode=debug
will give you more readable code. I usually set my pubspec.yaml up like so:
transformers:
- $dart2js:
minify: false
checked: true
(or checked=false if I'm chasing a performance issue). Then running pub build
(without any arguments) will produce to desired output.
Produce a smaller use-case
If you can get Angular out of the mix, the Dart Team will have a much easier time debugging. Failing that, generate a AngularDart application that shows the error on page load.
Print statements
Adding print statements in Dart help you understand the execution flow, but also make it easy to search the dart2js output for good places to add breakpoints.
I find that source maps only confuse things and always disable them.
git bisect
Once you have a small enough use-case that triggers on page load, using git bisect to search your history for the breaking change is quick and impresses your friends.