Summary
build.ts rewrites Bun's generated output with regexes (var (init_src\d*) = __esm(...), init_config(); → await init_config();) to keep setConfig writing the same config binding readers use. The in-file comments document that this already silently broke once (a config3 → config5 rename made an earlier patch a no-op). Any Bun bundler change to wrapper naming / __esm shape breaks setConfig silently again, with no test guarding it.
Suggested fix
Store config on a globalThis[Symbol.for('bun-query-builder/config')] ??= { ...defaultConfig } singleton and export const config = .... That removes both the export let split-binding hazard and the entire build.ts patch (no module-local binding for the bundler to rename/wrap). Pitfalls to note: a Symbol.for singleton is shared across all package versions in a process (dedup risk if two majors coexist), and it doesn't fix the documented multi-dialect cross-contamination — but it's strictly less fragile than patching emitted JS. At minimum, add a post-build assertion that setConfig({dialect:'sqlite'}) actually flips a reader.
Severity: medium (robustness). Relates to #1022. Found via internal code audit.