https://www.boundaryml.com logo
🟡 Inquiry on baml toolchain for static source ana...
# questions
r
Hey all, just wondering if in the baml toolchain there is a supported api or cli for static source analysis? I mean beyond compilation and symbol description? I am thinking something like tserver? or ts-morph? It's not a hard issue for me, but does shape a decision for me in the project I am using to explore baml
v
we have recently added full reflection into the runtime! Though it doesn't yet have span information and such.
reflect.Package.compile(<code>)
we are currently thinking about making a clippy equivalent (linter) that can be extendable by BAML defined code and as a part of that, i suspect we'd expose AST + typechecking functions directly in BAML so you can parse various things.
but on the latest version of BAML, sadly not yet built. we do hope its going to be there soon as a linter kind of toolchain is somewhat essential to prevent "sloppy" patterns
b
Can we ask what the decision is?
We’re expecting to launch 1.0 in the new few months, and it sounds like you’d like to have some form of AST stability in that launch, but it would help to know what kind of stability you’d like to see from us
r
I am exploring some ideas about code reviews that focus on architecture and design and using this to explore baml at the same time. I was thinking about dog fooding the process with baml code but I would need some static source analysis tools. I can just as easily build some typescript for this. Hence the decision - I will use baml to own the cli, orchestration, and typescript dependency isolation, and the model part. Then I can dog food with the typescript dependencies that do the rule evaluations using ts-morph, etc
b
I think my recommendation is to fork the BAML toolchain - if you have your agent inspect the implementation of
baml describe
and
baml lsp
, there's quite a lot of work that's gone into the compiler to produce well-defined symbols. Re-implementing that yourself would be challenging to get right reliably. The first few compiler phases are relatively stable at this point - there are some things that are still evolving - but between the two options of 1. rolling your own TS parser/lexer + IR + type checker to get something that works on 70% of code, and 2. reusing the production BAML toolchain internals that works on 99% of code, and updating it when BAML compiler internals change I think (2) is a more attractive maintenance burden for you, even if we can't make promises about the AST stability
r
cheers for that I will rejoin the baml meetings soon love what's going on here