Add getLoggers() to list loggers in a category tree - #207
Conversation
There's currently no way to find out which loggers exist at runtime, which makes it hard to build things like a debug panel that lets users toggle categories on and off, or just to double check what logging is actually active in an app. getLoggers() walks the category tree from a given logger (or the root by default) and returns every logger in that subtree, including the one you passed in, in depth-first order. It only sees loggers that have actually been created via getLogger() somewhere, not every category that's been configured — that limitation is called out in the docstring. Closes dahlia#62 Assisted-by: Claude Code:claude-sonnet-5
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #207 +/- ##
==========================================
- Coverage 86.00% 85.93% -0.08%
==========================================
Files 70 71 +1
Lines 12980 13015 +35
Branches 2925 2939 +14
==========================================
+ Hits 11164 11184 +20
- Misses 1288 1297 +9
- Partials 528 534 +6 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
dahlia
left a comment
There was a problem hiding this comment.
Thanks for your contribution.
Could you run mise run fmt for formatting?
Also, it would be great if this feature is documented in the VitePress docs (docs/).
Adds a "Listing loggers" section to docs/manual/categories.md, and adds the PR number and contributor credit to the changelog fragment, per review feedback on dahlia#207. Assisted-by: Claude Code:claude-sonnet-5
|
Thanks for the feedback!
Pushed as 490bdfd. |
dahlia
left a comment
There was a problem hiding this comment.
The code is still not well-formatted!
Collapse the ternary in collectDescendants() back to one line, per CI's deno fmt --check failure. Assisted-by: Claude Code:claude-sonnet-5
|
This feature will be shipped with the next minor release, LogTape 2.4.0. Meanwhile, you could try v2.4.0-dev.865+57354081, a pre-release build. |
Closes #62.
Right now there's no way to find out which loggers exist in a running program. If you're building something like a debug panel where users can toggle categories on and off, or you just want to sanity-check what logging is active, you have to already know every category name up front.
This adds
getLoggers(), which walks the category tree from a given logger (or the root, by default) and returns every logger in that subtree, including the one you passed in, in depth-first order:It also accepts a
Logger, a category string, or a category array, same asgetLogger().One thing worth calling out (this came up in the discussion on #62): it only sees loggers that have actually been created via a
getLogger()call somewhere in the program, not every category that's been set up throughconfigure(). If a category is only reached lazily inside a function that hasn't run yet, it won't show up. That's documented in the docstring.Testing
Added tests in
logger.test.tscovering: a fresh/never-touched category, a multi-level subtree in depth-first order, identity withgetLogger(), the no-argument default, an untouched descendant being correctly omitted, and deadWeakRefentries being skipped without being pruned from the tree.Ran the Node test suite locally (
pnpm testinpackages/logtape) — all passing. I wasn't able to rundeno check/deno lint/mise run checkin my environment (nodeno/miseinstall available), so it'd be good to have CI confirm those.AI disclosure: This PR was written with assistance from Claude Code (claude-sonnet-5) — design discussion, implementation, and tests. I reviewed and tested everything locally before submitting. See
Assisted-bytrailers in the commit.