do you want to handle all errors gracefully?
or just wait for #13

do you want to handle all errors gracefully? or just wait for #13

Independent of #13, it's important that all invalid patterns throw with a custom message. How narrow/specific those errors should be (and how much information should be included in the message) is partly a matter of taste, so it might depend on the case.

Where to throw errors might also be a bit ambiguous, but probably has a "correct" answer in most cases, be it in the tokenizer, the parser's parse<X> function, or the parser's create<X> function (which can be called separately of the parsing process). In some cases (probably somewhat more cases than is currently done) it might also be important to include redundant error handling in the generator, in case an AST is manipulated in an invalid way after parsing.

tf is wrong with git
I say merge upstream main
and it merges my downstream forked main

I do it again
and it then correctly merges the upstream main
huhhh

I even checked the commit hashes

EDIT:
fixed it!! 🎉

Great stuff! 🎉🚀 Thanks for putting up with the back and forth, and doing excellent work on this.

I've made some follow-up tweaks and added some tests in 1ea0179. Some changes are just nitpicky style and personal preference things (or done for consistency with code elsewhere), but a handful are worth observing. One probably non-obvious thing is I removed a couple uses of Array.isArray because I think it's worse to explicitly ignore the unexpected fact that arguments came in as a type other than null or an array (and therefore avoid throwing on subsequent use of array methods). Obviously we could add custom error checking, etc. but this seemed like something in between that was a slight improvement (although that's probably subjective).

removeUselessCalloutArguments was an ideal name for consistency and explicitness. I only changed it (to simplifyCallouts) because it was long.

looks good

when renaming and modifying files
I like to split it across 2 commits
that way if git sees that the 2 files are like 95% the same across the commit
it'll link the commit history between them

I wasn't sure that [] ? true : false would equal true
but it seems it does ✅️
cause "" becomes false

Good advice on splitting commits. I'll try to do that in the future.

Published in v0.9.0.