Hello, I'm an open source software engineer in my late 30s living in #Seoul, #Korea, and an avid advocate of #FLOSS and the #fediverse.
I'm the creator of @fedify, an #ActivityPub server framework in #TypeScript, @hollo, an ActivityPub-enabled microblogging software for single users, and @botkit, a simple ActivityPub bot framework.
Just shared my thoughts on #JavaScript library #logging on Hacker News. Explores the fragmentation problem and dependency dilemmas from a library author's perspective. Would love to hear feedback from the #winston/#Pino users.
Building a JavaScript library is a delicate balance. You want to provide useful functionality while being respectful of your users' choices and constraints. When it comes to logging—something many libraries need for debugging, monitoring, and user support—this balance becomes particularly challenging.
The JavaScript ecosystem has evolved various approaches to this challenge, each with its own trade-offs. LogTape offers a different path, one that's specifically designed with library authors in mind.
The current state of library logging
If you've built libraries before, you've probably encountered the logging dilemma. Your library would benefit from logging—perhaps to help users debug integration issues, trace internal state changes, or provide insights into performance bottlenecks. But how do you add this capability responsibly?
Currently, popular libraries handle this challenge in several ways:
The debug approach
Libraries like Express and Socket.IO use the lightweight debug package, which allows users to enable logging through environment variables (DEBUG=express:*). This works well but creates a separate logging system that doesn't integrate with users' existing logging infrastructure.
Custom logging systems
Libraries like Mongoose and Prisma have built their own logging mechanisms. Mongoose offers mongoose.set('debug', true) while Prisma uses its own logging configuration. These approaches work, but each library creates its own logging API that users must learn separately.
Application-focused libraries
winston, Pino, and Bunyan are powerful logging solutions, but they're primarily designed for applications rather than libraries. Using them in a library means imposing significant dependencies and potentially conflicting with users' existing logging choices.
No logging at all
Many library authors avoid the complexity entirely, leaving their libraries silent and making debugging more challenging for everyone involved.
Dependency injection
Some libraries adopt a more sophisticated approach by accepting a logger instance from the application through their configuration or constructor parameters. This maintains clean separation of concerns and allows libraries to use whatever logging system the application has chosen. However, this pattern requires more complex APIs and places additional burden on library users to understand and configure logging dependencies.
Each approach represents a reasonable solution to a genuine problem, but none fully addresses the core tension: how do you provide valuable diagnostic capabilities without imposing choices on your users?
The fragmentation problem
There's another challenge that emerges when libraries each solve logging in their own way: fragmentation. Consider a typical Node.js application that might use Express for the web framework, Socket.IO for real-time communication, Axios for HTTP requests, Mongoose for database access, and several other specialized libraries.
Each library potentially has its own logging approach:
Authentication libraries often include their own logging mechanisms
From an application developer's perspective, this creates a management challenge. They must learn and configure multiple different logging systems, each with its own syntax, capabilities, and quirks. Logs are scattered across different outputs with inconsistent formats, making it difficult to get a unified view of what's happening in their application.
The lack of integration also means that powerful features like structured logging, log correlation, and centralized log management become much harder to implement consistently across all the libraries in use.
LogTape's approach
LogTape attempts to address these challenges with what might be called a “library-first design.” The core principle is simple but potentially powerful: if logging isn't configured, nothing happens. No output, no errors, no side effects—just complete transparency.
This approach allows you to add comprehensive logging to your library without any impact on users who don't want it. When a user imports your library and runs their code, LogTape's logging calls are essentially no-ops until someone explicitly configures logging. Users who want insights into your library's behavior can opt in; those who don't are completely unaffected.
More importantly, when users do choose to configure logging, all LogTape-enabled libraries can be managed through a single, unified configuration system. This means one consistent API, one log format, and one destination for all library logs while still allowing fine-grained control over what gets logged from which libraries.
Note
This approach isn't entirely novel—it draws inspiration from Python's standard logging library, which has successfully created a unified logging ecosystem. In Python, libraries like Requests, SQLAlchemy, and Django components all use the standard logging framework, allowing developers to configure all library logging through a single, consistent system. This has proven to be both practical and powerful, enabling rich diagnostic capabilities across the entire Python ecosystem while maintaining simplicity for application developers.
// In your library code - completely safe to includeimport { getLogger } from "@logtape/logtape";const logger = getLogger(["my-awesome-lib", "database"]);export function connectToDatabase(config) { logger.debug("Attempting database connection", { config }); // ... your logic logger.info("Database connection established");}
The dependency consideration
Modern JavaScript development involves careful consideration of dependencies. While popular logging libraries like winston and Pino are well-maintained and widely trusted, they do come with their own dependency trees. winston, for example, includes 17 dependencies, while Pino includes 1.
For library authors, this creates a consideration: every dependency you add becomes a dependency for your users, whether they want it or not. This isn't necessarily problematic (many excellent libraries have dependencies), but it does represent a choice you're making on behalf of your users.
LogTape takes a different approach with zero dependencies. This isn't just a philosophical choice—it has practical implications for your library's users. They won't see additional packages in their node_modules, won't need to worry about supply chain considerations for logging-related dependencies, and won't face potential version conflicts between your logging choice and theirs.
At just 5.3KB minified and gzipped, LogTape adds minimal weight to their bundles. The installation process becomes faster, the dependency tree stays cleaner, and security audits remain focused on the dependencies that directly serve your library's core functionality.
Breaking the compatibility chain
Here's a challenge that might be familiar: you want your library to support both ESM and CommonJS environments. Perhaps some of your users are working with legacy Node.js projects that rely on CommonJS, while others are using modern ESM setups or building for browsers.
The challenge becomes apparent when you have dependencies. While ESM modules can import CommonJS modules without issues, the reverse isn't true—CommonJS modules cannot require ESM-only packages (at least not until the experimental features in Node.js 22+ become stable). This creates an asymmetric compatibility constraint.
If your library depends on any ESM-only packages, your library effectively becomes ESM-only as well, since CommonJS environments won't be able to use it. This means that even one ESM-only dependency in your chain can prevent you from supporting CommonJS users.
LogTape supports both ESM and CommonJS completely, meaning it won't be the weak link that forces this limitation. Whether your users are working with legacy Node.js projects, cutting-edge ESM applications, or hybrid environments, LogTape adapts seamlessly to their setup.
More importantly, when LogTape provides native ESM support (rather than just being importable as CommonJS), it enables tree shaking in modern bundlers. Tree shaking allows bundlers to eliminate unused code during the build process, but it requires the static import/export structure that only ESM provides. While CommonJS modules can be imported into ESM projects, they're often treated as opaque blocks that can't be optimized, potentially including unused code in the final bundle.
For a logging library that aims to have minimal impact, this optimization capability can be meaningful, especially for applications where bundle size matters.
Universal runtime support
The JavaScript ecosystem spans an impressive range of runtime environments today. Your library might run in Node.js servers, Deno scripts, Bun applications, web browsers, or edge functions. LogTape works identically across all of these environments without requiring polyfills, compatibility layers, or runtime-specific code.
This universality means you can focus on your library's core functionality rather than worrying about whether your logging choice will work in every environment your users might encounter. Whether someone imports your library into a Cloudflare Worker, a Next.js application, or a Deno CLI tool, the logging behavior remains consistent and reliable.
Performance without compromise
One concern library authors often have about logging is performance impact. What if your users import your library into a high-performance application? What if they're running in a memory-constrained environment?
LogTape addresses this with remarkable efficiency when logging is disabled. The overhead of an unconfigured LogTape call is virtually zero—among the lowest of any logging solution available. This means you can add detailed logging throughout your library for development and debugging purposes without worrying about performance impact on users who don't enable it.
When logging is enabled, LogTape consistently outperforms other libraries, particularly for console output—often the most common logging destination during development.
Avoiding namespace collisions
Libraries sharing the same application can create logging chaos when they all output to the same namespace. LogTape's hierarchical category system elegantly solves this by encouraging libraries to use their own namespaces.
Your library might use categories like ["my-awesome-lib", "database"] or ["my-awesome-lib", "validation"], ensuring that your logs are clearly separated from other libraries and the main application. Users who configure LogTape can then control logging levels independently for different libraries and different components within those libraries.
Developer experience that just works
LogTape is built with TypeScript from the ground up, meaning your TypeScript-based library gets full type safety without additional dependencies or type packages. The API feels natural and modern, supporting both template literals and structured logging patterns that integrate well with contemporary JavaScript development practices.
// Template literal style - feels naturallogger.info`User ${userId} performed action ${action}`;// Structured logging - great for monitoringlogger.info("User action completed", { userId, action, duration });
Practical integration
Actually using LogTape in your library is refreshingly straightforward. You simply import the logger, create appropriately namespaced categories, and log where it makes sense. No configuration, no setup, no complex initialization sequences.
import { getLogger } from "@logtape/logtape";const logger = getLogger(["my-lib", "api"]);export async function fetchUserData(userId) { logger.debug("Fetching user data", { userId }); try { const response = await api.get(`/users/${userId}`); logger.info("User data retrieved successfully", { userId, status: response.status }); return response.data; } catch (error) { logger.error("Failed to fetch user data", { userId, error }); throw error; }}
For users who want to see these logs, configuration is equally simple:
If your potential users are already invested in other logging systems, LogTape provides adapters for popular libraries like winston and Pino. This allows LogTape-enabled libraries to integrate with existing logging infrastructure, routing their logs through whatever system applications are already using.
The existence of these adapters reveals an honest truth: LogTape isn't yet a widely-adopted standard in the JavaScript ecosystem. Most applications are still built around established logging libraries, and asking users to completely restructure their logging approach would be unrealistic. The adapters represent a practical compromise—they allow library authors to take advantage of LogTape's library-friendly design while respecting users' existing investments and preferences.
This approach reduces friction for adoption while still providing library authors with a modern, zero-dependency logging API. Perhaps over time, as more libraries adopt this pattern and more developers experience its benefits, the need for such adapters might diminish. But for now, they serve as a pragmatic bridge between LogTape's vision and the current reality of the ecosystem.
A choice worth considering
Ultimately, choosing LogTape for your library represents a particular philosophy about the relationship between libraries and applications. It's about providing capabilities while preserving choice, offering insights while avoiding imposition.
The traditional approaches—whether using debug packages, application-focused loggers, or custom solutions—each have their merits and have served the community well. LogTape simply offers another option: one designed specifically for the unique position libraries occupy in the JavaScript ecosystem.
For library authors, this approach might offer several practical benefits. Your library gets detailed logging for development, debugging, and user support, while your users retain complete autonomy over whether and how to use those capabilities.
The broader benefit might be a more cohesive logging experience across the JavaScript ecosystem—one where libraries can provide rich diagnostic information that integrates seamlessly with whatever logging strategy applications choose to employ.
In a world where every dependency decision has implications, LogTape offers an approach worth considering: a way to enhance your library's capabilities while respecting your users' preferences and existing choices.
The secret to my productivity: I take every other day off, and when I do code, I get in the zone with music and allocate some time to respond to bug reports, check issues/discord/matrix, plan new features/work on new features and share recent progress.
I've been doing this for years, and while it may not work for everyone, it works for me.
FediDB was launched in 2019 and just got a fresh coat of paint in April.
Fediverse.info launched in 2021 and just this week was redesigned.
@dansup Your productivity is genuinely inspiring! Shipping 3 new sites while simultaneously refactoring and advancing multiple projects—that's incredible dedication. The fediverse ecosystem is fortunate to have someone so committed to moving things forward.
@hongminhee 저도 좀 비슷한 히스토리가 있어요. 중학생쯤 되면서 그동안 봐왔던 포켓몬같은 애니가 유치하게 느껴지고, 좀더 시리어스한 장르를 찾게 되었는데요. 그때 그런 수요를 맞춰주는 에반게리온, 페이트 이런거 재밌게 봤어요. 근데 그러고나서 더 딥다크한 애니를 찾진 않고 대신 마찬가지로 시리어스하고 좀더 핍진성 있는 미드/영드에 안착하게 되더라고요. 지금은 거의 범죄/공포/스릴러 드라마만 보고 살고있네요.
15年 전쯤인가, 當時 親하게 지내던 兄이 꽤 아는 게 많은 御宅였는데, 그 影響으로 나도 御宅가 되고 싶다고 생각했었다. 그런데 한 몇 個月 비슷하게 따라하려고 해도 흉내 낼 수가 없더라. 그래서 御宅 되기는 그 때 抛棄했다. 그래도 如前히 좋아하는 作品은 어릴 때 接했던 《エヴァンゲリオン》 시리즈 程度?
LogTape is a logging library designed specifically for the modern JavaScript ecosystem. It stands out with its zero-dependency architecture, universal runtime support across Node.js, Deno, Bun, browsers, and edge functions, and a library-first design philosophy that allows library authors to add logging without imposing any burden on their users. When LogTape isn't configured, logging calls have virtually no performance impact, making it the only truly unobtrusive logging solution available.
For a comprehensive overview of LogTape's capabilities and philosophy, see our introduction guide.
Milestone achievement
We're excited to announce LogTape 1.0.0, marking a significant milestone in the library's development. This release represents our commitment to API stability and long-term support. The 1.0.0 designation signals that LogTape's core APIs are now stable and ready for production use, with any future breaking changes following semantic versioning principles.
This milestone builds upon months of refinement, community feedback, and real-world usage, establishing LogTape as a mature and reliable logging solution for JavaScript applications and libraries.
Major new features
High-performance logging infrastructure
LogTape 1.0.0 introduces several performance-oriented features designed for high-throughput production environments. The new non-blocking sink option allows console, stream, and file sinks to buffer log records and flush them asynchronously, preventing logging operations from blocking your application's main thread.
The new fromAsyncSink() function provides a clean way to integrate asynchronous logging operations while maintaining LogTape's synchronous sink interface. This enables scenarios like sending logs to remote servers or databases without blocking your application.
For file operations specifically, the new getStreamFileSink() function in the @logtape/file package leverages Node.js PassThrough streams to deliver optimal I/O performance with automatic backpressure management.
New sink integrations
This release significantly expands LogTape's integration capabilities with two major new sink packages. The @logtape/cloudwatch-logs package enables direct integration with AWS CloudWatch Logs, featuring intelligent batching, exponential backoff retry strategies, and support for structured logging through JSON Lines formatting.
The @logtape/windows-eventlog package brings native Windows Event Log support with cross-runtime compatibility across Deno, Node.js, and Bun. This integration uses runtime-optimized FFI implementations for maximum performance while maintaining proper error handling and resource cleanup.
Beautiful development experience
The new @logtape/pretty package transforms console logging into a visually appealing experience designed specifically for local development. Inspired by Signale, it features colorful emojis for each log level, smart category truncation that preserves important context, and perfect column alignment that makes logs easy to scan.
As shown above, the pretty formatter supports true color terminals with rich color schemes, configurable icons, and intelligent word wrapping that maintains visual consistency even for long messages.
Ecosystem integration
Perhaps most significantly, LogTape 1.0.0 introduces adapter packages that bridge the gap between LogTape's library-friendly design and existing logging infrastructure. The @logtape/adaptor-winston and @logtape/adaptor-pino packages allow applications using these established logging libraries to seamlessly integrate LogTape-enabled libraries without changing their existing setup.
// Quick setup with winstonimport "@logtape/adaptor-winston/install";
// Or with custom configurationimport { install } from "@logtape/adaptor-winston";import winston from "winston";const logger = winston.createLogger({/* your config */});install(logger);
These adapters preserve LogTape's structured logging capabilities while routing everything through your preferred logging system, making adoption of LogTape-enabled libraries frictionless for existing applications.
Developer experience enhancements
This release includes several quality-of-life improvements for developers working with LogTape. The new getLogLevels() function provides programmatic access to all available log levels, while the LogMethod type offers better type inference for logging methods.
Browser compatibility has been improved, particularly for the @logtape/otel package, which previously had issues in browser environments due to Node.js-specific imports. The package now works seamlessly across all JavaScript runtimes without throwing module resolution errors.
Breaking changes and migration guide
LogTape 1.0.0 includes one notable breaking change: the removal of the deprecated LoggerConfig.level property. This property was deprecated in version 0.8.0 in favor of the more descriptive LoggerConfig.lowestLevel property.
If your configuration still uses the old property, simply rename it:
// Before (deprecated){ category: ["app"], level: "info", sinks: ["console"] }
For more complex filtering requirements, consider using the LoggerConfig.filters option instead, which provides more flexibility and supports inheritance from parent loggers.
Complete package ecosystem
LogTape 1.0.0 represents the culmination of a comprehensive package ecosystem, now consisting of 11 specialized packages that address different aspects of logging infrastructure. This modular approach allows you to install only the packages you need, keeping your dependency footprint minimal while accessing powerful logging capabilities when required.
Whether you're new to LogTape or upgrading from a previous version, getting started with 1.0.0 is straightforward. For new projects, begin with a simple configuration and gradually add the packages and features you need:
Existing applications using winston or Pino can immediately benefit from LogTape-enabled libraries by installing the appropriate adapter. For comprehensive migration guidance and detailed feature documentation, visit our documentation site.
The 1.0.0 release represents not just a version number, but a commitment to the stability and maturity that production applications require. We're excited to see what you'll build with LogTape.
번아웃으로 아직 고생하는 가운데, 갑자기 삘이 와서 지난 1주간 170쪽짜리 소설을 Gemini로 써 버렸다. 소재가 너무 잔혹해서 (R-18G 수준) 그대로 공개하기에는 꺼려진다는 문제가 있을 뿐; 줄거리 자체는 내가 예상한 것 이상으로 잘 나왔는데 퇴고를 열심히 해서 그런 것 같다. 구체적으로 어떻게 된 거냐 하면,
Gemini 2.5 Flash로 짧은 초안 작성 (1판)
이 초안의 중간 즈음에서 두 개의 새 줄거리를 만들어서 전체 줄거리 수가 3개가 됨
이대로는 안되겠다 싶어서 Flash의 제안을 일부 받아 들여 줄거리를 하나로 재조정 (2판)
이 시점에서 Gemini 2.5 Pro한테 평가를 부탁하고, 평가 내용을 다시 Flash에게 되먹여서 액션 아이템을 만들어 퇴고를 반복 (3~7판)
이 참에 번역도 맡겨야지 싶어서 Flash한테 먼저 초벌 번역을 시킴 (번역 1판)
초벌 번역을 Pro한테 주고 고쳐야 하는 부분을 그 이유와 함께 나열하게 함
Flash한테 수정된 번역과 수정한 이유들을 주고 판단하게 시킨 다음 최종 번역본을 완성 (번역 2판)
마지막으로 Pro한테 전체 번역문을 주고 전체 번역 안에서의 일관성이 깨진 게 있는지 확인
이랬는데, 가장 곤란했던 건 역시 4였다. 왜냐하면 내용이 너무 길어서 텍스트 창에는 한 번에 안 들어가고(...), 잘라서 넣으면 이제 뭔 짓을 해도 앞부분을 까먹어 버렸기 때문이다. 최종적으로 동작한 방법은 소설을 최대 32KB 크기가 되도록 쪼갠 뒤 파일로 나눠어 업로드하고, 업로드가 끝난 뒤에 몇장까지 있는지 확인하고 뒤가 잘린 문장이 있는지 확인해서 뭔가 문제가 있으면 평가를 하지 않고 멈추라고 지시한 것. 혹시 이런 일 해야 하는 분은 참고하시길.
...뭐 이렇게 말하긴 했는데 사실 Flash한테 글 쓰기는 다 맡겼지만 세부적으로는 상당히 손을 많이 거쳤다. 한국어나 영어 번역이나 둘 다 그랬음. 나름 노력한 것도 있고 이 전체 내용을 다시 Flash한테 되먹였더니 찬사 일색(!!!!!)이라 진짠가 싶어서 어디 올려야 할 것 같긴 한데 소재가 소재다 보니 공개도 간단하지 않다는 게 곤란하다. 호옥시 관심 있으신 분께서는 메일로 pdf 파일을 보내 드리겠습니다.
ALT text details소설 "싱크로니시티"의 한국어판 목차. 이하 다음과 같은 내용임:
싱크로니시티 Synchronicity
2025-06-22T00Z (7.4판), Gemini 2.5 Flash를 이용해 작성됨
프롤로그 - 2
1: 마리오네트 Marionette - 3
2: 태동 Genesis - 7
3: 틀 Frame - 13
4: 수치 Shame - 23
5: 목격 Witness - 37
6: 고난 Ordeal - 50
7: 울림 Resound - 65
8: 결점 Flaw - 73
9: 촉매 Catalyst - 82
10: 개조 Augment - 90
11: 의식 Ritual - 102
12: 쇼 Show - 108
13: 갈채 Acclaim - 117
14: 욕구 Desire - 130
15: 목도 Encounter - 141
16: 이미지 Image - 147
17: 진화 Evolution - 158
에필로그 - 163
'작가'의 변 - 164
작가의 변 - 166
'서평' - 170
For the past year I've been working on an activitypub federated instant messenger called Shoot. I haven't had time to work on it for a while because of my job, so I'm making it public to see if anyone would be interested in helping out.
Featureset currently includes: - Dm channels - Friends/relationships - Guilds - Guild channels - Guild invites - Voice calls (not yet federated) - Mostly working federation with itself - Iffy federation with other platforms
There's no official instance yet, but I could host one if there is interest.
What I need help with most is: - Frontend development. The client code is very hacky and gross, let alone the UI haha - Safety features - Probably general architecture stuff
