Skip to content
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

Debug log implementation pollutes other packages' output #366

Open
claabs opened this issue Oct 29, 2021 · 1 comment
Open

Debug log implementation pollutes other packages' output #366

claabs opened this issue Oct 29, 2021 · 1 comment
Labels
enhancement New feature or request good first issue Good for newcomers help wanted Extra attention is needed

Comments

@claabs
Copy link

claabs commented Oct 29, 2021

Many npm packages that provide debug logging do so with a package like debug. In the case of debug, packages namespace their logs so you can pinpoint where debug logs are output from.

Unfortunately, the way secret-agent uses the DEBUG environment variable, it will output some overkill logs even when I namespaced to another package (e.g. DEBUG=my-package).

It would be nice if the log output wasn't just a truthy on the DEBUG, but instead was namespaced (e.g. DEBUG=secret-agent or DEBUG=secret-agent:error). For bonus points, it could even look for its namespace in an advanced value like DEBUG=connect:bodyParser,connect:compress,connect:session,secret-agent

@blakebyrnes
Copy link
Contributor

blakebyrnes commented Oct 29, 2021

@claabs great points. When we ported SecretAgent out of Ulixee, we were plugging in a "pino" logger via the commons logger, and we left this bare-bones logger in place that is definitely putting out too much by default.

You can also inject a logger that uses the debug module if you want to. There's no public documentation right now, but you could inject a logger (

export function injectLogger(builder: (module: NodeModule) => ILogBuilder): void {
) looking at the code that assigned debug targets to the modules (each log entry passes in the code module).

We'll make that variable more meaningful for the default case. That sounds like something I've been wanting lately as well

@blakebyrnes blakebyrnes added enhancement New feature or request good first issue Good for newcomers help wanted Extra attention is needed labels Jan 28, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request good first issue Good for newcomers help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

2 participants