Hey I'm interested in working on BAML as a first time contributor. Can anybody please guide me to doing so? Thank you.

If anyone is looking to contribute to BAML, we are open to implementing the TOON output format, but would need someone to potentially aid in getting this through. There is already an open-source crate to parse this format, just need to format BAML types into the prompt in this format: https://crates.io/crates/toon-format/0.3.0

we would need a similar design spec like this: https://gloochat.notion.site/XML-Outputs-218bb2d26216806fb4dfef242d150c51?source=copy_link for how types are rendered

Hi @aaronv (BAML) I willing to take this up.

Anyone successfully run the dev setup script? I keep getting python build issues. Seems to be picking up my system python 3.14 instead of the configured 3.13.

Proposal(s) for Image-output DX: https://github.com/BoundaryML/baml/issues/2746 @aaronv (BAML)

Have you guys tried toon in large complex structured data? Looking at TOON I am not even getting the conviction to even get my hands dirty with this.

Hey everyone! I think I’ve found a bug in the TypeScript client codegen. When a BAML function has a parameter named options, e.g.:

fn Foo(options: ConfigOptions) -> Bar

the generated TypeScript client creates a function like:

async Foo(options: ConfigOptions, __baml_options__?) {
  const options = { ...this.bamlOptions, ...(__baml_options__ || {}) };
  ...
  this.runtime.callFunction("Foo", { options });
}

Because the parameter

options

and the internal variable

const options

use the same name, the parameter gets shadowed and the runtime receives the wrong value resulting in

[BAML ERROR]: Invalid parameters for BAML function Foo

It seems like other parameter names could also clash with internal locals (e.g. signal, collector, env, raw, etc.). Should I open a GitHub issue for this (didn't find anything similar)?

Hi @emil! Can you please check out this PR: https://github.com/emilsoman/baml_elixir/pull/8 It adds ability to pass the client registry with every call. This makes it possible to e.g. pass custom headers unique to each requests, e.g. for tracing routers like Helicone.

Hi, I'm running BAML in EKS and hit a limitation with the aws-bedrock provider. It doesn't support IRSA (IAM Roles for Service Accounts) authentication. IRSA sets

AWS_WEB_IDENTITY_TOKEN_FILE

+

AWS_ROLE_ARN

, but BAML only reads explicit credentials (

AWS_ACCESS_KEY_ID

, etc.). This is the AWS equivalent of the Vertex WIF issue ([#2560](https://github.com/BoundaryML/baml/issues/2560)). I've got a workaround using the AWS SDK to exchange the token for temp credentials and pass them to ClientRegistry, but native support would be cleaner. The Rust aws-config crate already has WebIdentityTokenCredentialsProvider in its default chain, so it might be straightforward to add. Worth opening an issue for this? Happy to provide more details or help contribute a fix.

Hey everyone 👋 - I've run into a bit of a blocker at my work re: running BAML on x86 alpine It appears that the musl build isn't clean of glibc references... (The cause of [#1466](https://github.com/BoundaryML/baml/issues/1466)). Running ldd within my container gives me this:

> [build 6/6] RUN ldd /app/node_modules/.../baml.linux-x64-musl.node && exit 1:
0.122   /lib/ld-musl-x86_64.so.1 (0x7ffffff5a000)
0.123   libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x7ffffccaf000)
0.123   libc.so.6 => /lib/ld-musl-x86_64.so.1 (0x7ffffff5a000)
0.123   ld-linux-x86-64.so.2 => /lib/ld-linux-x86-64.so.2 (0x7ffffcca8000)
0.123 Error relocating /app/node_modules/.../baml.linux-x64-musl.node: __register_atfork: symbol not found
...

Admittedly, I'm a bit out of my depth here - but my understanding is that we shouldn't be seeing dynamic linking libraries with a musl output? This lead me to napi-rs. Poking around the docs there, I see a nice example on how to do cross-compilation, curiously, I notice they are using the

-x

(equivalent to

--cross-compile

) [option](https://github.com/napi-rs/cross-build/blob/77d4d8cd22fff4d27588a35d8cd2f26be9b39bd4/.github/workflows/pure-rust-build-on-linux.yml#L33) for the musl targets (instead of

--use-napi-cross

). I wonder if reflecting this change would fix the issue? I've attempted to try this locally, but I'm having a hard time getting the build to work - would anybody mind lending me a hand with this? Oh, and Merry Christmas! 🎄

How can I contribute to the Markdown Editor project?

Hey everyone! We've started using BAML with our Typescript/Ruby services and I noticed the published ruby Gem is a bit out of date. I found #[2620](https://github.com/BoundaryML/baml/issues/2620) and wondered if I could help out, or if anyone else is currently working on it?

Noticed an interaction with bun test and BAML runtime where any test that imports from baml client and has a sync test will always hang and the process will timeout, making running tests in a codebase that uses baml at all very annoying reproduced the specific problem here: https://github.com/anerli/baml-bun-test-hang-repro not sure what the correct solve would be but would be great to not have to constantly tell my coding agent to make all tests async just to work around this :P

Hey folks, I've been looking into what it would take to get the TS client working in CF Workers and I'd like to help get this over the line if there's interest. From what I can tell, most of the hard runtime work is already done -

baml-schema-wasm

compiles the full runtime to WASM and already makes real LLM calls (the playground uses it). The gap is that it exposes a playground/IDE API rather than the `callFunction`/`streamFunction`/`TypeBuilder` etc. API that the generated client code expects. My rough read on what's left: - Add

callFunction

,

streamFunction

,

buildRequest

,

TypeBuilder

,

ClientRegistry

,

RuntimeContextManager

as

#[wasm_bindgen]

exports to

baml-schema-wasm

(the pattern is already there via

run_tests

) - A thin

wasm-entry.js

shim in

language_client_typescript

that initialises the WASM and re-exports everything under the same interface as the NAPI module -

package.json

export conditions (

workerd

,

browser

) pointing at the shim - A couple of small

process.env

/

process.on

guards in

async_context_vars.ts

-

wasm-pack build

wired into the publish pipeline alongside the existing

napi build

Before I start digging in I wanted to ask: 1. Is this actually wanted? Don't want to open a big PR into a dead end 2. Is

baml-schema-wasm

the right place to add these bindings or should they live in a new crate? 3. Any known blockers I've missed - e.g. WASM binary size concerns, streaming edge cases? 4. Preferred way to contribute - draft PR early, or work something out in an issue first? Happy to take a stab at the Rust bindings side if the direction is clear.

Hey everyone! My name is Miguel Serna (MFS-code on gh) and I'm looking at making the BAML plugin for Neovim. I recently read the blog post https://boundaryml.com/blog/ai-agents-need-new-syntax which mentions Neovim support is coming soon, but I can't find any work started on it (besides an existing community plugin that's syntax-only). Since baml-cli lsp already works over stdio, all the hard pieces seem to be in place. I also found two small bugs in the LSP server I'd be happy to PR, code_action_provider is set to None despite having an implementation, and will_save is advertised but unhandled. Am I good to start work on this or is there anything I should consider before digging in?

Hi team 👋 I'd like to contribute. Can I work on issue #793 (Pydantic error when BAML classes use composition)? The problem: the generated baml_client/types.py lists classes in alphabetical order, so a class that references another class defined later (e.g. A uses B) breaks Pydantic's model rebuild and throws an error. Is this still open to work on? Happy to confirm the approach before I open a PR. Thanks!

Hey! We’d be happy to accept a PR here- the places to look at are engine/generators/languages/python and integ-tests/python ; tools/build will have a section on how to run the integ tests We probably just need to update the generators to forward-decl all refs to other classes, instead of changing the order (since cross-file imports would cause issues with any ordering scheme)

Hey @baml-sam PR for #793 is up: https://github.com/BoundaryML/baml/pull/3819 Like you said, I didn't reorder the classes. Instead the generator now adds model_rebuild() for every class at the end of types.py/stream_types.py, so forward refs work no matter the order. (Pydantic v1 uses update_forward_refs().) Tested on py3.9 + pydantic 2.1.0 up to the latest, plus v1 — all good, tests green. Let me know if you want any changes

Explain to me how pydantic v1 vs pydantic v2 works

so basically both v1 and v2 are used to parsed the llm output in the user defined structure, it just that model rebuild compiled the validation logic of each class written in type.py, due to which converting the llm output into class object become faster for v2,where as in v1 we have the just python code for validation which is basically a interpreted language, and its validation is slow and in our pr, for 2.1.0 pydantic verstion we have the issue of forward ref, so we explicitly mention the model rebuild at last, so model resbuild is doing both work : handling forward reference and giving compiled validation logic but only in case pydantic v2, for v1 it just solve the forward reference.

I've been having codex go through and write a detailed report of various potential windows issues with a particular focus on path handling. It's found quite a few areas where bugs could surface. Is this the type of thing that should be documented in a design doc? I'm planning on going through each potentially problematic surface, reading the code around it and having codex explain it's purpose to me then coming up with an appropriate plan to fix it with future maintainability in mind. I'm happy to document the purpose/intent/decision making behind each of these changes for future reference as well as coming up with a brief guide for how to avoid readding these types of buggy surfaces in the future if you think that'd be useful for the project. Also plan on adding/fixing tests so the current sketchy surfaces don't later regress. With agents my hope is that testing + examples of good path handling should help nudge most new code towards better path handling going forward even without providing them with explicit guidance. If you do want me to document this stuff you'll just have to point me to where/how you want it documented alongside any guidance for doing so and then I'll figure it all out. I'm still early in this process mostly just interrogating codex for good concrete info across the entire project and I don't plan on actually implementing the wide range of fixes until after I've come back with a proposed plan to share with you. However if I'm going to be documenting the decision making involved it's best if I do that while making the actual decisions instead of adding it later. @baml-sam

I found a bug with namespaces/graph view and fixed it. https://github.com/BoundaryML/baml/pull/3997

Hi! I’m looking into the current Nix setup and wanted to ask what the intended support scope is before opening any PR. Right now it looks like

flake.nix

has accumulated a lot of different responsibilities. It’s ~ 800 lines and includes both a dev shell and package outputs for CLI/Python/TypeScript, including debug/release, musl, and Darwin handling. As far as I can tell, all Nix logic lives in that one file; I don’t see a separate

nix/

structure, checks, formatter, docs, or Nix CI. It also seems to build from the older

engine/

workspace, while the current Rust dev docs point contributors to

baml_language/

. On top of that, the Linux dev shell looks currently broken because it references removed

pkgs.llvmPackages_17.libclang

.

.envrc

also auto-selects

use flake

whenever

nix-shell

exists, and it sets

RUSTC_WRAPPER=baml-sccache

, but the Nix shell doesn’t include

sccache

. So I’m wondering what maintainers want to do with Nix: 1. Keep it as dev-shell-only: then maybe simplify it, fix Linux/sccache, and remove or mark package outputs unsupported. 2. Support real packaging: then it probably needs a redesign around

baml_language/

, explicit supported systems, checks/CI, and a proper

nix/

structure. 3. Treat it as unofficial/best-effort or external: then maybe keep upstream minimal and let a separate

baml-nix

flake handle packaging. If upstream is interested in supported Nix packaging, I’d be willing to work on a refactor and split things into a

nix/

directory, similar in spirit to

packaging/aur

, instead of keeping everything inside one large

flake.nix

. Curious what direction you’d prefer.

greetings folks ! I have been exploring the repo for a while now and was planning to contribute . Since this issue is a year old , i wanted to confirm if it is good to pick up ? - https://github.com/BoundaryML/baml/issues/2111

Hi everyone, I'm saime428. I've been looking through the BAML repo and would like to help with issue #3690: https://github.com/BoundaryML/baml/issues/3690 It looks like Go codegen emits an unused

valueHolder

when every field in a class is

null

. I'm thinking of adding a focused regression test and making the smallest change needed for the generated Go code to compile. Is the issue still available, and does that approach make sense?

i believe this is an issue with the older BAML engine that's being deprecated soon, feel free to make a fix for it, but we aren't prioritizing work on the old engine at the moment

Opened a PR for baml.iter: adds take, skip, take_while, and skip_while following the existing adapter pattern (same shape as StepBy/Chain/Peekable). https://github.com/BoundaryML/baml/pull/4510 Following the note about the stdlib being the higher-value area over the legacy DSL issues, I audited baml.iter and found the sharpest gap: Repeat.new(value) defaults to an infinite iterator with no way to bound it — collect/reduce warn against calling them on an infinite iterator, but nothing in the module could actually stop one. Repeat.new(0).take(5) now works and terminates. This came out of investigating a compiler crash I filed earlier: https://github.com/BoundaryML/baml/issues/4506 — reaching for .take() on an infinite Repeat is what first surfaced it, though the crash turned out to be a separate, broader bug (inferred generic type arguments through a factory function), not specific to iterators. CodeRabbit caught a real correctness bug in the first pass (quota was consumed before confirming the source yielded an item) — fixed and covered with new tests, now approved. 15 original tests + 4 review-fix tests, full suite green.

Hi! Question about baml.sys process APIs + possible PRs. Context: we're evaluating BAML (0.17.1 nightly, baml pack) for a cross-platform dev-process supervisor CLI — start/stop/restart long-lived dev services across separate CLI invocations, managed via pid files. I found sys.start_process + the Process handle (kill/wait/streaming stdout) in the nightly — that covers the core spawn use case nicely. Three gaps remain for our scenario: 1. No pid accessor on Process — we can kill via the handle but can't learn the child's pid, so cross-invocation management (start now, kill later from a different process) isn't possible. 2. No detached/setsid option in ProcessOptions — the child shares the parent's process group and stderr; there's no way to daemonize or redirect stdio to log files. 3. No pid-based operations — e.g. sys.kill(pid, signal) or a liveness check (kill(pid, 0) equivalent); Process.kill() also appears to be force-kill only, no graceful SIGTERM. Would you take PRs for these? Happy to discuss API shape (e.g. Process.pid: int, ProcessOptions.detached, sys.signal(pid, sig)) in whatever direction you prefer — or to hear it's intentionally out of scope.

message has been deleted