Known v0.10 limitations (documented, now tracked)
The TS/JS resolver (fieldnotes/symbols.py) is deliberately parser-free — regex declaration match + line-based brace balancing. Two real limitations:
- Multi-line template literals containing braces aren't stripped by
_strip_ts_noise (it only handles single-line strings), so a declaration whose body contains e.g. a multi-line template with ${...} or CSS-in-JS braces can misbalance the scan and produce a wrong end line. Failure mode is loud (pin surfaces as stale), but wrong-range pins waste a heal cycle.
- No dotted notation for TS (
ClassName.method) — Python has it via AST; TS resolves top-level declarations only.
Direction
Keep the no-parser stance (a wrong range fails loud, and zero deps is a feature). For (1), a line-state tracker for backtick spans would cover most cases. For (2), a second-pass scan inside a matched class block for methodName( at one indent level would cover the common case. PRs welcome — see the test conventions in tests/test_symbols_ts.py.
Known v0.10 limitations (documented, now tracked)
The TS/JS resolver (
fieldnotes/symbols.py) is deliberately parser-free — regex declaration match + line-based brace balancing. Two real limitations:_strip_ts_noise(it only handles single-line strings), so a declaration whose body contains e.g. a multi-line template with${...}or CSS-in-JS braces can misbalance the scan and produce a wrong end line. Failure mode is loud (pin surfaces as stale), but wrong-range pins waste a heal cycle.ClassName.method) — Python has it via AST; TS resolves top-level declarations only.Direction
Keep the no-parser stance (a wrong range fails loud, and zero deps is a feature). For (1), a line-state tracker for backtick spans would cover most cases. For (2), a second-pass scan inside a matched class block for
methodName(at one indent level would cover the common case. PRs welcome — see the test conventions intests/test_symbols_ts.py.