Nested fields in message templates resolve against the top-level attributes

[ayaangazali]

While reading packages/logfire-api/src/formatter.ts I noticed nested template fields like {a.b} don't traverse into the attribute value. In getField (the loop around line 65) every path segment after the first is looked up in the top-level record instead of the object being walked, so one of two things happens:

import * as logfire from 'logfire'

// 1. falls back to the raw template
logfire.info('hello {user.name}', { user: { name: 'Alice' } })
// message: "hello {user.name}" plus a "Formatting error: The field user.name is not defined." warning

// 2. silently renders an unrelated attribute when a top-level key shares the trailing segment name
logfire.info('value is {a.b}', { a: { b: 'nested' }, b: 'top' })
// message: "value is top"

Expected (matching Python Logfire, which resolves dotted fields into the value): "hello Alice" and "value is nested". Reproduced on current main. The second case is the nasty one since there's no warning, just a wrong value in the message. Bracket syntax like {a[0]} also doesn't resolve, but that looks more like a missing feature than a wrong result, so I left it alone.

I took a stab at a fix on my fork: https://github.com/ayaangazali/logfire-js/tree/nested-template-fields (built with Claude Code's help, went through the diff myself). It walks the path segments into the value, keeps literal dotted keys like http.method winning over traversal so existing OTel-style attribute names don't change behavior, and adds a formatter.test.ts covering the cases above plus a changeset. pnpm run check is green. happy to open a PR if the approach looks right, or totally fine if it's easier to handle on your end. still learning this codebase, would love any pointers :)

[petyosi]

Thanks for the detailed report — confirmed on main, and the silent wrong-value case is indeed the nasty one. I ran your branch locally: the approach looks right (a literal dotted key winning over traversal is the correct call, since OTel-style attribute names like http.method are flat keys), all package tests pass and typecheck is clean. Please open the PR.

Two things worth addressing in it:

1. Dropping the includes('[') branch changes bracket syntax behavior: on main, {a[0]} silently renders the string undefined; with your fix it warns and falls back to the raw template. That's an improvement, but please mention it in the changeset.
2. The nested traversal uses key in obj, which walks the prototype chain — {user.toString} with user: {} resolves the inherited method and renders native function source instead of failing. Main has the same quirk at the top level (fieldName in record), but since you're touching this code, switching both checks to Object.hasOwn would be stricter.

[ayaangazali]

thanks for checking the branch so quickly! opened the PR with both points addressed: Object.hasOwn everywhere (plus regression tests for {user.toString} and top-level {toString}) and the bracket-behavior change spelled out in the changeset.