feat: introduce logger

[araujogui]

Description

Introduces a logger with multiple transports (console and github)

Validation

npx doc-kit generate -i doc/api/*.md -t web -o out/

Related Issues

Fixes #329

Check List

• I have read the Contributing Guidelines and made commit messages that follow the guideline.
• I have run node --run test and all tests passed.
• I have check code formatting with node --run format & node --run lint.
• I've covered new added functionality with unit tests if necessary.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Preview	Updated (UTC)
api-docs-tooling	Ready	Preview	Aug 27, 2025 9:34pm

[Copilot]

Pull Request Overview

This PR introduces a new logger system with multiple transports (console and GitHub) to replace the existing reporter system in the linter. The new logger provides structured logging with levels, timestamps, and formatted output across different environments.

Key changes:

• Replaces the existing linter reporter system with a centralized logger infrastructure
• Adds support for console and GitHub Actions transports with proper formatting
• Updates CLI interface to use transport terminology instead of reporter terminology

Reviewed Changes

Copilot reviewed 19 out of 26 changed files in this pull request and generated 4 comments.

File	Description
src/logger/	New logger infrastructure with constants, utilities, transports, and singleton pattern
src/linter/index.mjs	Updated to use new logger system instead of reporters
src/linter/reporters/	Removed old reporter files
README.md	Updated CLI documentation to reflect transport terminology

Comments suppressed due to low confidence (1)

src/logger/tests/logger.test.mjs:195

• This test is marked with it.only which means other tests in this file will be skipped during execution. This should be removed to ensure all tests run.

  it.only('should log error message', t => {

[avivkeller]

Will this work on generators? Since, they are each offloaded to a desperate thread?

What if, and it may be far too complicated, we send the logging data back to the parent thread, which has the instantiated logger class, to then handle the incoming data with the appropriate transport, drppping the need to statically have a getInstance. (We could also re-instantiate the logger on the children, which may be simpler)

Like,

ThreadedLogger.error(...)

on("log", (group, level, message, etc) =>

[ovflowd]

Will this solution also work with progress bars?

[codecov]

Codecov Report

❌ Patch coverage is 99.15433% with 8 lines in your changes missing coverage. Please review.
✅ Project coverage is 74.71%. Comparing base (1318d28) to head (c29dd1a).
⚠️ Report is 2 commits behind head on main.
✅ All tests successful. No failed tests found.

Files with missing lines	Patch %	Lines
src/logger/index.mjs	88.88%	3 Missing ⚠️
bin/commands/interactive.mjs	0.00%	2 Missing ⚠️
bin/utils.mjs	50.00%	1 Missing ⚠️
src/logger/transports/github.mjs	97.61%	1 Missing ⚠️
src/logger/utils/colors.mjs	94.44%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #367      +/-   ##
==========================================
+ Coverage   72.26%   74.71%   +2.45%     
==========================================
  Files          96      107      +11     
  Lines        9486    10430     +944     
  Branches      586      679      +93     
==========================================
+ Hits         6855     7793     +938     
- Misses       2629     2635       +6     
  Partials        2        2              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[avivkeller]

@araujogui OOC is there a package that does this all for us?

[araujogui]

@araujogui OOC is there a package that does this all for us?

Well, pino is the best option I know

[avivkeller]

What about signale?

import signale from "signale";

signale.error("...");
signale.pending("...");

It looks like it should be easy to globally configure (https://github.com/klaudiosinani/signale#settingsobj). Each generator can have it's own scope

[araujogui]

What about signale?

import signale from "signale";

signale.error("...");
signale.pending("...");

It looks like it should be easy to globally configure (https://github.com/klaudiosinani/signale#settingsobj). Each generator can have it's own scope

It seems like a good option, but I would like the team to discuss this better before I invest more time into this pr. @nodejs/web-infra

[avivkeller]

Can we blocked this PR until nodejs/nodejs.org#8057 lands, and linting is removed from here, since it'll change up the transports?

[ovflowd]

LGTM! Left a few comments for improvements.

[araujogui]

@ovflowd @avivkeller can we reach a consensus about whether using in-house logger or something else? before I put more time in this pr

[avivkeller]

I'm okay with landing this as is (and unlocking it, since remark-lint needs my TLC before it can land).

We can always change it later.

[araujogui]

@ovflowd rebased, can i merge?

[avivkeller]

I still don't love the whole getInstance, I'd prefer using a library that does this all for us / a no-instance alternative

We really don't need transports, tbh.

I'm not going to block, but now that we don't need transports (since we don't have linting), I think we should not add them in this PR

[araujogui]

@avivkeller I believe the GitHub transport can come in handy because we mostly run this in CI

[ovflowd]

I'm not going to block, but now that we don't need transports (since we don't have linting), I think we should not add them in this PR

Could you elaborate?

I still don't love the whole getInstance,

You mean the Singleton approach or?

[ovflowd]

@araujogui IMO we don't need the getInstance method since we already do a default export. Can you remove the Singleton approach? The logger should export a named Logger function/constant (like you do) that allows you to create a new Logger instance and that instance is stored within a variable + have the default export being an instance.

This ensures that:

• Default import is "the" Singleton
• You can still create more non-default instances.

But we don't need a getInstance or wrapper/storing ref to the instances globally.

[avivkeller]

Could you elaborate?

I poorly worded my comment. I didn't like that transports seemingly required this to use a getInstance method, but, I was mistaken. My concerns have been self resolved.

You mean the Singleton approach or?

Yes.