-
Notifications
You must be signed in to change notification settings - Fork 16
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
base: main
Are you sure you want to change the base?
Conversation
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
There was a problem hiding this 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 => {
There was a problem hiding this 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) =>
Will this solution also work with progress bars? |
src/logger/transports/console.mjs
Outdated
* @param {import('../types').TransportContext} context | ||
* @returns {void} | ||
*/ | ||
export const console = ({ |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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 = (() => { |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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?
Codecov Report❌ Patch coverage is
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. 🚀 New features to boost your workflow:
|
@araujogui OOC is there a package that does this all for us? |
Well, pino is the best option I know |
What about 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 |
Description
Introduces a logger with multiple transports (
console
andgithub
)Validation
npx doc-kit generate -i doc/api/*.md -t web -o out/
Related Issues
Fixes #329
Check List
node --run test
and all tests passed.node --run format
&node --run lint
.