LogTape: zero-dependency structured logging for JavaScript libraries and applications

The library-first design: logging in shared packages without forcing configuration on consumers

The problem LogTape targets is one library authors run into regularly. A library that imports a logger with its own configuration pushes that configuration into every application that depends on it, and if the application also has its own logger, the two configurations can conflict. LogTape's answer is that a library can log without any configuration at all: when no sink is configured, every logging call is silent, and an application that wants to see those records sets up a sink in its own startup code.

This works because the category system is shared across the entire process. A library logs under its own category, and the application can filter or silence that category at the application level without touching anything in the library's code. The library support documentation at logtape.org/manual/library describes the expected setup pattern in detail.

Zero transitive dependencies are what make this practical for shared package distribution. A library that adds @logtape/logtape to its package.json brings in one entry with no further packages below it. Bundlephobia at bundlephobia.com/package/@logtape/logtape shows the dependency count directly, and the README badge row links to it for verification.

Hierarchical categories as the mechanism for controlling log level per subsystem

Categories are the organizational unit in LogTape, and they form a tree where child categories inherit the log level of their parent unless a child has an explicit override. This means controlling the verbosity of any subsystem is a matter of setting one category-level rule, without changing global configuration or touching any other category.

In a project that uses several libraries alongside application code, this matters concretely: enabling debug output from one library's category leaves the rest of the tree at its configured level. Filtering at the sink level also uses categories, so errors from a database query category can go to a monitoring service while debug logs from an HTTP category go to the local console, with each sink receiving only the categories it is configured to accept. The category documentation is at logtape.org/manual/categories.

The hierarchical structure means category naming conventions matter at library authoring time. A library that logs under a nested path like ["mylib", "db", "queries"] gives the consuming application granular control: it can address the db level, the queries sublevel, or the whole mylib tree, rather than having to match a flat string. Choosing a flat single-segment category loses that granularity permanently, because it cannot be subdivided after the fact without a breaking change.

Installing @logtape/logtape and configuring the first sink

Both the JSR and npm registries carry the core package under the same name, @logtape/logtape. Install commands differ by runtime and package manager:

deno add jsr:@logtape/logtape  # for Deno
npm  add     @logtape/logtape  # for npm
pnpm add     @logtape/logtape  # for pnpm
yarn add     @logtape/logtape  # for Yarn
bun  add     @logtape/logtape  # for Bun

After installing, the first step is registering a sink. Without at least one sink, all logging calls are silent regardless of log level or category, because that is the intended behavior when a library consumer has not opted into seeing the output. The sinks documentation at logtape.org/manual/sinks covers the built-in options and the interface for writing a custom one.

The @logtape/config package provides an object-based configuration helper for teams that prefer to define logging settings in a plain object or data file rather than calling the configuration API in code. It is a separate package in the monorepo, installed alongside the core as needed.

The same import works in a Deno module, a Node.js script, a Bun process, a browser and an edge function, with no code change between them. That runtime portability depends on no native bindings, which is a direct consequence of the zero-dependency design.

Structured logging, template literal messages and built-in data redaction

Log records in LogTape carry key-value pairs alongside the message text, keeping the fields as discrete data rather than embedding them in a formatted string that a downstream tool would have to parse. This is what the README means by structured logging support, and it interacts directly with the category and sink system: a sink for a metrics backend can extract specific fields from the record without needing to match a regular expression against a log line.

Messages use template literal syntax. A call can include placeholders that are evaluated at log time, which means the values are available as structured data in the record rather than being concatenated into the message string before any filtering happens. The README points to logtape.org/manual/start#how-to-log for the specific syntax.

Data redaction is built into the core package. 2 approaches are available: pattern-based redaction targets values that match a shape across all fields, while field-based redaction targets specific named keys in the structured data. A rule masking a field named token, for example, applies everywhere that key appears in a record, without modifying the call site. Both approaches are documented at logtape.org/manual/redaction, along with their interaction when multiple rules apply to the same record.

4 adaptor packages for existing loggers; 6 framework integrations in the packages table

Adaptor packages bridge existing loggers to LogTape sinks. 4 of them are listed in the monorepo: @logtape/adaptor-bunyan, @logtape/adaptor-pino, @logtape/adaptor-log4js and @logtape/adaptor-winston. Each connects an existing logger's output to LogTape's sink system, so a codebase already using Pino or winston can gain LogTape functionality at the output layer without replacing every logging call.

For teams evaluating Pino as an alternative to LogTape on Node.js, @logtape/adaptor-pino exists for mixed-adoption scenarios where both loggers are present. Pino is the logging library most frequently paired with high-throughput Node.js services, and using the adaptor is the lower-cost adoption path compared to a full migration.

6 framework integration packages appear in the table: @logtape/express, @logtape/fastify, @logtape/graphql-yoga, @logtape/hono, @logtape/drizzle-orm and @logtape/elysia. Koa is also named in the README's framework list, though the table is truncated before that entry. Each integration hooks into the framework's request lifecycle or query events to produce structured records automatically, with no manual instrumentation at the call site. @logtape/cloudwatch-logs is the only cloud-hosted sink listed, routing records to AWS CloudWatch Logs.

No generic HTTP sink in the package list, and no GitHub releases for automated changelog tracking

No generic HTTP sink, no Datadog integration, no Sentry connector and no persistent file sink appear in the packages table. For a team that needs log records to reach one of those services, a custom sink implementation is the path, because none of those destinations are covered by the packages listed in the README.

GitHub releases are absent from the repository. Automated dependency management tools like Dependabot or Renovate can still track version bumps through the JSR or npm registry, but the changelog link in an automated pull request will point to the registry listing rather than a GitHub release page. CHANGES.md at the repository root is where version history is maintained.

For applications on Node.js where logging throughput is a primary concern, Pino is the main alternative to evaluate. @logtape/adaptor-pino exists for codebases that already use Pino and want to route its records through LogTape sinks rather than migrating call sites.

MIT licence, last push on 2026-10-06, and AI contributor governance files

MIT is the licence, with no restrictions on commercial use or redistribution. Last push was on 2026-10-06, and the repository is not archived.

Upgrade cost is low for a zero-dependency library: no native modules need rebuilding, and no transitive dependency version bumps can cause unexpected failures. Breaking changes in LogTape itself are what CHANGES.md tracks, and the stable surfaces at risk are the sink API and the category configuration interface.

AI_POLICY.md, AGENTS.md, CLAUDE.md and a .agents/ directory appear in the top-level entries. These are governance documents for AI-assisted development rather than user-facing documentation, indicating the author has explicit written policies for code agents that contribute to the repository. Contributors encounter these files; end users of the library do not.

Logtape.org hosts the full manual, with separate pages for installation, categories, structured logging, redaction, sinks and framework integrations.

Editorial conclusion

LogTape fits library authors who need logging that imposes nothing on consuming applications, and teams targeting Deno, Bun or edge runtimes where @logtape/logtape provides explicit runtime support. For applications that need a remote transport outside of AWS CloudWatch, expect to write a custom sink: the packages table lists no generic HTTP sink or Datadog/Sentry integration. Before adopting in a library, check logtape.org/manual/library for your scenario, and note that version tracking runs through JSR or npm package numbers rather than GitHub release tags.

Frequently asked questions

Official sources

1. dahlia/logtape on GitHub
2. Issues
3. License: MIT
4. Project website
5. README