question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

[FEATURE REQUEST] Provide context per class

See original GitHub issue

Is your feature request related to a problem? Please describe.

I’m using globally imported pino logger module. Every time when I make a log line I would like to know from which class the log was created. Right now, I have to include the context manually. Like the following lines in the README.md: https://github.com/iamolegga/nestjs-pino/blob/master/README.md#L56 https://github.com/iamolegga/nestjs-pino/blob/master/README.md#L72

Currently, we can set base context per configuration of logger module. That’s too broad for my use case. Even if I migrate my logger module import from global to per module import, I’d prefer finer level of granularity in defining base context. (But not as fine as log line 😃 )

Describe the solution you’d like

I would like to write log lines using injected logger without manually providing class context on each log line. I’d like the context to be either set up once per class (injection) or somehow dynamically configured to use class name (or whatever else) per module configuration.

I’m probably off on these, but my superficial suggestions would be:

  • configure the module with an option to always fork a child logger for each class it’s injected into OR
  • expose child functionality so we can fork (child) a logger manually. Then we could set it up with context in each class constructor (or wherever we deem useful)

Issue Analytics

  • State:closed
  • Created 4 years ago
  • Comments:17 (10 by maintainers)

github_iconTop GitHub Comments

1reaction
iamoleggacommented, Oct 17, 2019

I would agree with @trymoto because I would prefer to KISS, and actually get rid of all not necessary extra API, and make library users not to remember complex API with this @PinoLogger.Inject or InjectLogger.

I think that injecting it as regular service is more preferred, and makes setting context optional, so PinoLogger users may use it without required context setting, and use it just like pino and not thinking about context property, that actually came up from LoggerService 🤔

1reaction
iamoleggacommented, Oct 17, 2019

Hey, I’ve almost done with it, but just need add tests and docs, so I guess it will be shipped in several hours. The api of new PinoLogger will be like:

import { Controller, Get } from "@nestjs/common";
import { MyService } from "./my.service";
import { PinoLogger } from "../src/PinoLogger";

@Controller()
export class AppController {
  constructor(
    private readonly myService: MyService,
    @PinoLogger.Inject("MY_CONTEXT_VALUE") private readonly logger: PinoLogger
  ) {}

  @Get()
  getHello(): string {
    this.logger.info("getHello(%O)", arguments); // <-- "info" and  "trace" methods (like pino has) as opposite to "log" and "verbose" (like LoggerService has)
    return `Hello ${this.myService.getWorld()}`;
  }
}

And I’m still in doubt, which varian of injection and setting context is better:

  1. via @PinoLogger.Inject like above or
  2. via normal injection and manually setting context:
import { Controller, Get } from "@nestjs/common";
import { MyService } from "./my.service";
import { PinoLogger } from "../src/PinoLogger";

@Controller()
export class AppController {
  constructor(
    private readonly myService: MyService,
    private readonly logger: PinoLogger
  ) {
    logger.context = "MY_CONTEXT_VALUE";
  }

  @Get()
  getHello(): string {
    this.logger.info("getHello(%O)", arguments); // <-- "info" and  "trace" methods (like pino has) as opposite to "log" and "verbose" (like LoggerService has)
    return `Hello ${this.myService.getWorld()}`;
  }
}

@maricn @valerio-battaglia what do you think?

Read more comments on GitHub >

github_iconTop Results From Across the Web

Managing feature requests: A comprehensive guide - UserVoice
Feature requests are invaluable opportunities to discover ways to improve your product and better serve your users' ever-evolving needs. A smooth feature ...
Read more >
Cloud Feature Requests | CircleCI Ideas
When using the "Run Pipeline" feature, the name of the parameter is currently left blank, and open to incorrect use. It would be...
Read more >
10 Tips for Responding Graciously to Customer Feature ...
Picture this scenario: A customer requests a feature. Support politely tells them that it can't be done while still providing top quality service....
Read more >
Taking advantage of context features - Recommenders
Importance of context: if user preferences are relatively stable across contexts and time, context features may not provide much benefit.
Read more >
Request Features in ASP.NET Core | Microsoft Learn
Each feature interface provides a granular subset of the functionality exposed by HttpContext . These interfaces can be added, modified, ...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found