洪 民憙 (Hong Minhee)

Hello! I'm Hong Minhee (洪 民憙), an open source software engineer in my late 30s, living in Seoul, Korea. I'm bisexual and non-binary (they/them), and an enthusiastic advocate of free/open source software and the fediverse.

I work full-time on @fedify, an ActivityPub server framework in TypeScript, funded by @sovtechfund. I'm also the creator of @hollo, a single-user ActivityPub microblog; @botkit, an ActivityPub bot framework; Hackers' Pub, a fediverse platform for software developers; and LogTape, a logging library for JavaScript and TypeScript.

I have a long interest in East Asian languages (CJK) and Unicode. I post mostly in English here, though occasionally in Japanese or in mixed-script Korean (國漢文混用體), a traditional writing style that interleaves Chinese characters with the native Korean alphabet. Wanting to write in that style was actually one of the reasons I joined the fediverse. Feel free to talk to me in English, Korean, Japanese, or even Literary Chinese!

#introduction

はじめまして！ソウル在住の30代後半のオープンソースソフトウェアエンジニア、洪 民憙（ホン・ミンヒ）と申します。バイセクシュアル（bisexual）・ノンバイナリー（non-binary）で、自由・オープンソースソフトウェア（F/OSS）とフェディバース（fediverse）の熱烈な支持者です。

STF（@sovtechfund）の支援を受け、TypeScript用ActivityPubサーバーフレームワーク「@fedify」の開発に専念しています。他にも、おひとり様向けのActivityPubマイクロブログ「@hollo」、ActivityPubボットフレームワーク「@botkit」、ソフトウェア開発者向けフェディバースプラットフォームHackers' Pub、JavaScript・TypeScript用ロギングライブラリLogTapeなどの制作者でもあります。

東アジア言語（いわゆるCJK）とUnicodeにも興味があります。このアカウントでは主に英語で投稿していますが、時々日本語や国漢文混用体（漢字ハングル混じり文）の韓国語でも書いています。実はこの文体で書きたくてフェディバースを始めた、という経緯もあります。日本語、英語、韓国語、漢文でも気軽に話しかけてください！

#自己紹介

安寧(안녕)하세요! 저는 서울에 살고 있는 30代(대) 後半(후반)의 오픈 소스 소프트웨어 엔지니어 洪民憙(홍민희)입니다. 兩性愛者(양성애자)(bisexual)이자 논바이너리(non-binary)이며, 自由(자유)·오픈 소스 소프트웨어(F/OSS)와 聯合宇宙(연합우주)(fediverse)의 熱烈(열렬)한 支持者(지지자)이기도 합니다.

STF(@sovtechfund)의 支援(지원)을 받아 TypeScript用(용) ActivityPub 서버 프레임워크 @fedify 開發(개발)에 專業(전업)으로 任(임)하고 있습니다. 그 外(외)에도 싱글 유저用(용) ActivityPub 마이크로블로그 @hollo, ActivityPub 봇 프레임워크 @botkit, 소프트웨어 開發者(개발자)를 위한 聯合宇宙(연합우주) 플랫폼 Hackers' Pub, JavaScript·TypeScript用(용) 로깅 라이브러리 LogTape 等(등)의 製作者(제작자)이기도 합니다.

東(동)아시아 言語(언어)(이른바 CJK)와 Unicode에도 關心(관심)이 많습니다. 이 計定(계정)에서는 主(주)로 英語(영어)로 포스팅하지만, 때때로 日本語(일본어)나 國漢文混用體(국한문 혼용체) 韓國語(한국어)로도 씁니다. 聯合宇宙(연합우주)에 오게 된 動機(동기) 中(중) 하나가 바로 國漢文混用體(국한문 혼용체)로 글을 쓰고 싶었기 때문이기도 하고요. 韓國語(한국어), 英語(영어), 日本語(일본어), 아니면 漢文(한문)으로도 말을 걸어주세요!

#툿친소 #연친소 #별친소 #자기소개

주말에 튜사 모각코하실분 있나요~

@heybran Oh, yeah, scallions are what my brother (who cooked that 麻婆豆腐) missed! That would be even more delicious…

동생이 만들어 준 麻婆豆腐(마파두부)!

If you're building a JavaScript library and need logging, you would love LogTape
https://hackers.pub/@hongminhee/2025/logtape-for-libraries
#ycombinator

If you're building a JavaScript library and need logging, you would love LogTape

https://hackers.pub/@hongminhee/2025/logtape-for-libraries

#javascript

Requiring CW for all politics only works for people who have life that is not marked as "political"

Just learned of a self-hostable ticketing software called Pretix: https://pretix.eu/

It looks extremely full-featured.

the story behind the 🥚logo

@stefan Oh, great. I'll try translating it into Korean and Japanese when I have time.

If you'd like to help translate the site, you can learn about our workflow here: https://github.com/jointhefediverse-net/jointhefediverse.net#translation

#fediverse #JoinTheFediverse #SpreadTheFediverse #language #translation #internationalization #i18n #HelpWanted #volunteer

@hongminhee Oh nice, thank you! I updated the dark/light designs in https://github.com/jointhefediverse-net/jointhefediverse.net/tree/main/public/images/qr-code.

On a related note, if you happen to know anyone who'd be interested in helping translate https://jointhefediverse.net to these languages, definitely feel free to pass this along!

https://stefanbohacek.online/@stefan/110458472416790508

@stefan Could you add Korean and Japanese words for fediverse?

• 聯合宇宙
• 연합우주
• フェディバース

And @vitest would've been perfect, but it doesn't work with @deno_land either… 😞

Trying to build a cross-runtime test suite that works on Node.js, Bun, and Deno, but hitting a roadblock with Bun's incomplete node:test implementation. Missing subtests/test steps support is making this harder than it should be.

ここからはひたすらFedifyの実装を読み解きながら動作が違う部分を探して直すだけのお仕事 (苦行)

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.

https://news.ycombinator.com/item?id=44351881

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:

• Express uses DEBUG=express:*
• Socket.IO uses DEBUG=socket.io:*
• Mongoose uses mongoose.set('debug', true)
• Axios might use axios-logger or similar packages
• Redis clients have their own debug configurations
• 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.

// In your library code - completely safe to include
import { 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 natural
logger.info`User ${userId} performed action ${action}`;

// Structured logging - great for monitoring
logger.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:

import { configure, getConsoleSink } from "@logtape/logtape";

await configure({
  sinks: { console: getConsoleSink() },
  loggers: [
    { category: ["my-lib"], lowestLevel: "info", sinks: ["console"] }
  ]
});

Bridging the transition

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.

@Yozumina 강아지들은 살짝 격하게 쓰다듬어 주는 걸 더 좋아해요 ㅎㅎㅎ

Announcing LogTape 1.0.0 https://lobste.rs/s/obalic #javascript
https://hackers.pub/@hongminhee/2025/announcing-logtape-1-0

@nesroch 오… 그렇군요!! 😲

계촌법은 다시 봐도 어렵다

鼻祖(비조)
↑
遠祖(원조)
↑
太祖(태조)
↑
烈祖(열조)
↑
天祖(천조)
↑
高祖(고조)
↑
曾祖(증조)
↑
祖父(조부)
↑
父親(부친)
↑
自身(자신)
↓
子女(자녀)
↓
孫子(손자)
↓
曾孫(증손)
↓
玄孫(현손)
↓
來孫(내손)
↓
晜孫(晜손) (昆孫(곤손))
↓
仍孫(잉손)
↓
雲孫(운손)
↓
耳孫(이손)

https://g0v.social/@cafebug/114726748811582431

原來祖宗18代的scope是這樣啊 ...

@hongminhee Wow, thank you so much!

Your productivity and vision with Fedify continue to amaze me.

Seeing established players adopt it must be incredibly validating.

Thanks for all you do for the ecosystem ❤️

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.

I love it ❤️

@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.

Some people say I have too much on my plate, but may not realize how productive I can be.

This past week I shipped 3 new websites:
- https://fediverse.info
- https://fedithreat.net
- https://fedicon.ca

But I also:

- refactored FediThreat and successfully tested it, while also integrating support into Pixelfed

- shipped a new Pixelfed app release

- refactored the People Directory + crawler

- refactored the IG Import logic (shipping soon)

- prepared Loops first release

and more 😎

Well now who's the uncontrolled terrorist nation?

@hongminhee 저도 좀 비슷한 히스토리가 있어요. 중학생쯤 되면서 그동안 봐왔던 포켓몬같은 애니가 유치하게 느껴지고, 좀더 시리어스한 장르를 찾게 되었는데요. 그때 그런 수요를 맞춰주는 에반게리온, 페이트 이런거 재밌게 봤어요. 근데 그러고나서 더 딥다크한 애니를 찾진 않고 대신 마찬가지로 시리어스하고 좀더 핍진성 있는 미드/영드에 안착하게 되더라고요. 지금은 거의 범죄/공포/스릴러 드라마만 보고 살고있네요.

@thx 대신 振り(〈/pr〉후리)한글(?)을 달아 드렸습니다. ㅋㅋㅋ