Skip to content

feat: introduce logger #367

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 18 commits into
base: main
Choose a base branch
from
Open

feat: introduce logger #367

wants to merge 18 commits into from

Conversation

araujogui
Copy link
Member

@araujogui araujogui commented Jul 23, 2025

Description

Introduces a logger with multiple transports (console and github)

Validation

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

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.

@Copilot Copilot AI review requested due to automatic review settings July 23, 2025 22:14
@araujogui araujogui requested a review from a team as a code owner July 23, 2025 22:14
Copy link

vercel bot commented Jul 23, 2025

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name Status Preview Updated (UTC)
api-docs-tooling ✅ Ready (Inspect) Visit Preview Jul 25, 2025 8:48pm

Copy link
Contributor

@Copilot Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 => {

Copy link
Member

@avivkeller avivkeller left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Member

ovflowd commented Jul 23, 2025

Will this solution also work with progress bars?

* @param {import('../types').TransportContext} context
* @returns {void}
*/
export const console = ({
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder the compatibility of this for indeed work done by generators 🤔

Either generators will need to run their own logger instances individually if they want to log OR we only log high-level progress between each generator.

Although I'd wish the progress would be more granular:

  • for example instead of progress bar prgressing when each generator finishes, having it progress when each file gets updated is chef-kiss imo.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We could also send the logs to the parent, and have it to the processing, but that's more complex?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🤷 well worker_threads can communicate back and forth, Im fine with such comm.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We truly went the route of in-house logger?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As much as I like this, should maybe it be its own package then? I wonder the pros-cons of maintainin something like a logger in-house.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What do you mean? Do you want to create a new monorepo?

/**
* Singleton logger instance for consistent logging across the app.
*/
export const Logger = (() => {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think you need to wrap this whole thing as a function. You can just move this code to top level.

Or at least, do:

export const Logger = () => {}; // <- raw export of the factory.

export default Logger(); // <- default export of the singleton

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What about the transport param in the init method?

Copy link

codecov bot commented Jul 25, 2025

Codecov Report

❌ Patch coverage is 96.10516% with 40 lines in your changes missing coverage. Please review.
✅ Project coverage is 76.17%. Comparing base (9436edd) to head (30f3407).
⚠️ Report is 8 commits behind head on main.
✅ All tests successful. No failed tests found.

Files with missing lines Patch % Lines
src/linter/index.mjs 52.17% 11 Missing ⚠️
bin/commands/list.mjs 0.00% 9 Missing ⚠️
src/logger/index.mjs 85.45% 8 Missing ⚠️
bin/commands/lint.mjs 66.66% 4 Missing ⚠️
bin/commands/generate.mjs 25.00% 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   70.80%   76.17%   +5.36%     
==========================================
  Files         127      127              
  Lines       11620    11945     +325     
  Branches      694      779      +85     
==========================================
+ Hits         8228     9099     +871     
+ Misses       3389     2843     -546     
  Partials        3        3              

☔ 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
Copy link
Member

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

@araujogui
Copy link
Member Author

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

Well, pino is the best option I know

@avivkeller
Copy link
Member

avivkeller commented Jul 26, 2025

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
Copy link
Member Author

araujogui commented Jul 28, 2025

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Add custom console logger with Prefix
3 participants