Clojure stack traces in general are pretty verbose. A few thoughts from a fellow user (not ClojureScript specific, but remember we're doing all of this in a Clojure project):
The top few lines of the stack trace have the most information. Entering some blank space or clearing your terminal will make it easier to find the top.
The errors are often caught way down in Java land so you can be left trying to map Java errors and types into your own code - I've learned to ignore 80%+ of the trace for this reason.
There's a bit of a learning curve to figure out what this can't be cast to that might mean, both for Java types and Clojure types. For example a missing opening paren may give a (roughly) "number can't be cast to sequence" error. A missing closing paren will generally throw an End Of File (EOF) error.
A lot of the time you can get a line number from the top entry in the stack trace, they'll be in parentheses and aren't labeled terribly well - but once you find it once you'll know where it is forever.
Sometimes, in certain situations - especially with macros that call across files (like for testing) - the stack trace might be completely unhelpful.
I'm definitely hopeful that this situation will improve in the future (and maybe we can get an Edwin style debugger? Please?) In the meantime we can use tools to help us at least keep our braces organized since that's half the difficult to trace problems right there. For Emacs some swear by paredit, I'm still working on my system but it includes electric-parens, rainbow-parens (so helpful!) and auto-closing parens.
Also, it's not as robust as Emacs but Lighttable offers some decent parentheses handling out of the box (I went back to Emacs after Lighttable was making connections to outside servers that I at least didn't mean to ask it to and didn't have time to deal with. Other than that Lighttable was great).
The top few lines of the stack trace have the most information. Entering some blank space or clearing your terminal will make it easier to find the top.
The errors are often caught way down in Java land so you can be left trying to map Java errors and types into your own code - I've learned to ignore 80%+ of the trace for this reason.
There's a bit of a learning curve to figure out what this can't be cast to that might mean, both for Java types and Clojure types. For example a missing opening paren may give a (roughly) "number can't be cast to sequence" error. A missing closing paren will generally throw an End Of File (EOF) error.
A lot of the time you can get a line number from the top entry in the stack trace, they'll be in parentheses and aren't labeled terribly well - but once you find it once you'll know where it is forever.
Sometimes, in certain situations - especially with macros that call across files (like for testing) - the stack trace might be completely unhelpful.
I'm definitely hopeful that this situation will improve in the future (and maybe we can get an Edwin style debugger? Please?) In the meantime we can use tools to help us at least keep our braces organized since that's half the difficult to trace problems right there. For Emacs some swear by paredit, I'm still working on my system but it includes electric-parens, rainbow-parens (so helpful!) and auto-closing parens.
Also, it's not as robust as Emacs but Lighttable offers some decent parentheses handling out of the box (I went back to Emacs after Lighttable was making connections to outside servers that I at least didn't mean to ask it to and didn't have time to deal with. Other than that Lighttable was great).