BufferLogAppender now accepts threshold and optional size bounds via its
constructor, replaces bufferMax with the size target/max API, defaults
to bounded buffering, and may reassign its buffer during trim/clear
operations.
Also adds batched buffer trimming for high-throughput logging, a clamp
utility for bounds normalization, and expanded tests for buffer sizing,
trimming behavior, and clamp semantics.
The action is a GitHub Marketplace action
that doesn't exist on self-hosted Gitea instances. Replace it with
the standard curl-based Bun installation method and add ~/.bun/bin
to GITHUB_PATH.
- Runs on PRs targeting main and pushes to main
- Uses oven-sh/setup-bun@v2 to provision Bun
- Runs bun test v1.3.12 (700fc117) to validate the library
- Create test/ directory with a minimal LogService test
- Prove out the pattern: bun test natively discovers and runs tests
in the test/ directory using ESM-style imports from ../src/
Sometimes it is useful to capture log messages in a way that is easy for
the running program to introspect or manually handle.
*BufferLogAppender* captures the logs in a simple array.
Be careful, there is no default flush/clear mechanism that runs
automatically. Users of BufferLogAppender should take care to
render/handle log messages and periodically call `clearBuffer` on the
*BufferLogAppender* instance to avoid the buffer array growing without
limit.
console.trace generates and prints a full stacktrace for every log
message. This is not what TRACE means in this library. The TRACE level
is intended for logs that are more verbose than you typically want to
log and should only be turned on when you are trying to trace the
detailed behavior of the logged functionality. Printing the full stack
trace with every message makes an already verbose setting exponentially
worse.
Taking advantage of the new LogMessageFormatter return type, the
ConsoleLogAppender logs the formatted message as-is if it is a string,
but when processing structured data inserts a string summary consisting
of the message level, scope, and message summary or method. The full
object is still logged to the console as well for inspection.
Originally the idea was that a log formatter should turn the LogMessage
into a string that can be appended via a LogAppender. However, all of
the default LogAppenders can handle objects. In particular, the
ConsoleLogAppender writes to the browser console which offers an
interactive UI experience when logging raw objects.
For LogAppenders that can only manage text, it seems an acceptable
design decision to require users to provide a LogMessageFormatter that
returns a string, or accept some sane default like JSON.stringify if
their formatter returns objects.
- Added `flattenMessage` and `FlattenedLogMessage` to default to
structured logging.
- Rework the logic formatting messages for the ConsoleLogger.
- Add a more comprehensive README.
jdb
mahseiah_ai
Mahseiah