Skip to content

Feature request: logEvent method for manual usage #1006

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

Closed
3 tasks
dreamorosi opened this issue Jun 23, 2022 · 3 comments
Closed
3 tasks

Feature request: logEvent method for manual usage #1006

dreamorosi opened this issue Jun 23, 2022 · 3 comments
Labels
feature-request This item refers to a feature request for an existing or new utility good-first-issue Something that is suitable for those who want to start contributing logger This item relates to the Logger Utility rejected This is something we will not be working on. At least, not in the measurable future

Comments

@dreamorosi
Copy link
Contributor

Description of the feature request

Problem statement

PR #1004 introduced a new behaviour in the Logger decorator and middleware that allows to emit a log entry that contains the handler's event payload.

It would be great if this feature was available also for those users who don't use decorators or middy middleware.

In addition, a couple of changes related to this topic could be made in other sections:

  • Since in the docs we call out that this method is for debugging only, I'd expect the log level to be DEBUG instead of INFO.
  • In the packages/logger/src/middy.ts docstring of the injectLambdaContext middleware we should document the new flag/new behaviour so that it appears also in the API docs.
  • In the new sub-section of the docs where we show this method, it'd be nice to have a log excerpt. I was not sure which key the event would use in the JSON log (event duh).

Summary of the feature

Add public method like logger.logEvent(event);, as well as the changes listed above.

Code examples

N/A

Benefits for you and the wider AWS community

Better DX for users who want log the handler's event parameter during development / debugging but are not using middleware nor decorator.

Describe alternatives you've considered

Logging the event directly logger.debug('event', { event });

The above is not admittedly that bad, I convene that this proposal is purely syntactic sugar.

Additional context
N/A

Related issues, RFCs

#1004

@dreamorosi dreamorosi added enhancement good-first-issue Something that is suitable for those who want to start contributing logger This item relates to the Logger Utility labels Jun 23, 2022
@dreamorosi
Copy link
Contributor Author

I've marked this as good-first-issue, if anyone wants to pick it up please leave comment below and give a read to the CONTRIBUTING guidelines here.

@dreamorosi
Copy link
Contributor Author

Closing this issue since there hasn't been any movement/demand since it was opened.

If anyone is interested we'll consider re-opening.

@github-actions
Copy link
Contributor

⚠️ COMMENT VISIBILITY WARNING ⚠️

Comments on closed issues are hard for our team to see.
If you need more assistance, please either tag a team member or open a new issue that references this one.
If you wish to keep having a conversation with other community members under this issue feel free to do so.

@dreamorosi dreamorosi changed the title Feature (logger): logEvent method for manual usage Feature request: logEvent method for manual usage Nov 14, 2022
@dreamorosi dreamorosi added rejected This is something we will not be working on. At least, not in the measurable future feature-request This item refers to a feature request for an existing or new utility labels Nov 14, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature-request This item refers to a feature request for an existing or new utility good-first-issue Something that is suitable for those who want to start contributing logger This item relates to the Logger Utility rejected This is something we will not be working on. At least, not in the measurable future
Projects
None yet
Development

No branches or pull requests

1 participant