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

Feature suggestion: default replacer to better handle Error objects passed as meta #31

Closed
mfogel opened this issue Jan 2, 2021 · 5 comments
Assignees

Comments

@mfogel
Copy link

mfogel commented Jan 2, 2021

Hi, thanks a bunch for this project. Super helpful.

Right now, when passing Error objects in the meta parameter they get logged as {} because of the design of the Error object (as you know doubt know).

const log = require('lambda-log')
const error = new Error('foo')
log.warn('Heads up!', {error})
// {"_logLevel":"warn","msg":"Heads up!","error":{},"_tags":["log","warn"]}

I can use log.options.replacer to get a much better serialization of the Error object (using the error-to-json package here):

const log = require('lambda-log')
const errorToJson = require('error-to-json').default
log.options.replacer = (key, value) => {
  if (value instanceof Error) return errorToJson(value)
  return value
}

const error = new Error('foo')
log.warn('Heads up!', {error})
// {"_logLevel":"warn","msg":"Heads up!","error":{"name":"Error","message":"foo","stack":"Error: foo\n    at REPL9:1:15\n    at Script.runInThisContext (vm.js:120:18)\n    at REPLServer.defaultEval (repl.js:442:29)\n    at bound (domain.js:427:14)\n    at REPLServer.runBound [as eval] (domain.js:440:12)\n    at REPLServer.onLine (repl.js:777:10)\n    at REPLServer.emit (events.js:326:22)\n    at REPLServer.EventEmitter.emit (domain.js:483:12)\n    at REPLServer.Interface._onLine (readline.js:329:10)\n    at REPLServer.Interface._line (readline.js:658:8)"},"_tags":["log","warn"]}

My suggestion is to consider making this the default behavior. Are there any use cases where serializing an Error to {} would be the better behavior?

Thanks again for the project!

@KyleRoss
Copy link
Owner

@mfogel Right now, this package will handle Error objects correctly when passed in as the message versus within the meta. I can see the use cases where you may want to pass an error in the meta instead.

I'm trying to keep the number of dependencies within this package as minimal as possible so I think I would like to recreate the functionality of the error-to-json package inside of this one given it's a minimal amount of code.

I'll work on adding this in the next release. Thanks for the feature request!

@KyleRoss KyleRoss self-assigned this Feb 15, 2021
KyleRoss added a commit that referenced this issue Apr 9, 2021
KyleRoss added a commit that referenced this issue Apr 12, 2021
BREAKING CHANGE: Whenever an Error object is passed into the metadata for a log message, it will automatically be converted to a plain object as stringifying the an Error object will always yield `{}`.
github-actions bot pushed a commit that referenced this issue Apr 12, 2021
# [3.0.0](v2.4.0...v3.0.0) (2021-04-12)

### Bug Fixes

* add `.npmignore` file to help reduce the size of the package ([c21bd7f](c21bd7f))
* add `.npmignore` file to help reduce the size of the package ([9ccdc69](9ccdc69))
* do not use husky when on a CI environment ([a17ac76](a17ac76))
* reverse the check for LAMBDALOG_SILENT env variable ([95828b1](95828b1))
* reverse the check for LAMBDALOG_SILENT env variable ([5ab6dc5](5ab6dc5))

### Code Refactoring

* move message.tags to a getter and setter ([201a6fe](201a6fe))

### Features

* add ability for tags to be functions ([459380f](459380f))
* add ability for tags to be functions ([87ea24d](87ea24d))
* add ability to change the key names of the message output ([4a71909](4a71909))
* add ability to change the key names of the message output ([bc1169b](bc1169b))
* add new method `addLevel()` to LambdaLog ([9fde2e3](9fde2e3))
* add new method `addLevel()` to LambdaLog ([f7dbfd0](f7dbfd0))
* add new options `levelKey`, `messageKey`, and `tagsKey` ([bb5ba70](bb5ba70))
* add new options `levelKey`, `messageKey`, and `tagsKey` ([4d10968](4d10968))
* add new website! ([44a15dc](44a15dc))
* add new website! ([9aa6e2e](9aa6e2e))
* add symbols for referencing private properties in LogMessage ([f4b1c99](f4b1c99))
* add symbols for referencing private properties in LogMessage ([beb5e39](beb5e39))
* add symbols to reference certain private properties ([b502366](b502366))
* add symbols to reference certain private properties on LogMessage class ([952b62d](952b62d))
* convert Errors in metadata to plain objects [#31](#31) ([f55d474](f55d474))
* convert Errors in metadata to plain objects [#31](#31) ([576052a](576052a))
* remove default tags and add tag variable support [#29](#29) ([a43b0ae](a43b0ae))
* remove default tags and add tag variable support [#29](#29) ([ae686ef](ae686ef))
* set node engine to >= 10.0.0 ([0b5e564](0b5e564))
* set node engine to >= 10.0.0 ([2d022ec](2d022ec))
* switch from travis to github actions ([6ca053f](6ca053f))
* use jest for testing and coverage ([216141d](216141d))
* **internal:** add function to stub errors with a toJSON method ([b5e3dbe](b5e3dbe))
* switch from travis to github actions ([f2d418e](f2d418e))
* use jest for testing and coverage ([fafed5d](fafed5d))
* **internal:** add function to stub errors with a toJSON method ([d0707bd](d0707bd))

### BREAKING CHANGES

* There are no longer any built-in tags added to the tags array for each log message.
* `message.tags` is no longer a property of the LogMessage class that can be directly changed.
* Whenever an Error object is passed into the metadata for a log message, it will automatically be converted to a plain object as stringifying the an Error object will always yield `{}`.
* Previously you could directly access the private properties of LogMessage. In order to add some integrity, they are no longer using standard property names starting with an underscore and are instead referenced using symbols instead. For advanced usage, these symbols are exported as a static property on the LogMessage class under `LogMessage.symbols`.
* Previously you could directly access the private properties of LambdaLog. In order to add some integrity, they are no longer using standard property names starting with an underscore and are instead referenced using symbols instead. For advanced usage, these symbols are exported as a static property on the LambdaLog class under `LambdaLog.symbols`.
@KyleRoss
Copy link
Owner

@mfogel This has been implemented and published in v3.0.0. I'm still waiting on the site to go live with the updated documentation. Thanks for the feature suggestion!

@mfogel
Copy link
Author

mfogel commented Apr 12, 2021

Thanks @KyleRoss ! Appreciate it very much!

@KyleRoss
Copy link
Owner

@all-contributors please add @mfogel for ideas

@allcontributors
Copy link
Contributor

@KyleRoss

I've put up a pull request to add @mfogel! 🎉

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

No branches or pull requests

2 participants