-
Notifications
You must be signed in to change notification settings - Fork 32
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
feat(serializers): Implemented "error with cause" serializer #130
Conversation
- Created new serializer called "errWithCause". This serializer acts very similarly to the default "err" serializer. The differences: When it encounters an "error.cause" field, it serializes it recursively to create a nested object of errors. This is as opposed to the default error serializer, in which the resulting serialized object has no "cause" field, and the causes' messages & stack traces are appended to the original error.message and error.stack - Since some logic is reused between the existing err serializer and the new one, I moved some logic to the err-helpers file - Created a test-file for the new serializer. It is very similar to the existing err serializer test file since they should behave nearly identically. The differences are in the tests that test for the "cause" related behavior. - Upgrade tsconfig.json "lib" to support error.cause fields. pinojs#126
These tests fail for node v14. Working on a fix |
@@ -1,7 +1,7 @@ | |||
{ | |||
"compilerOptions": { | |||
"target": "es6", | |||
"lib": [ "es2015" ], | |||
"lib": [ "es2022" ], |
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.
wouldn't that be a breaking change? what is the reason for it?
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.
This is because I added a TS type test that creates an error with a cause
, but in lib: es2015 this isn’t supported so the test fails to compile.
I was under the impression that the lib config does not impact the users of this library, only the developers of the library. Am I wrong? If so I will revert this change.
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.
Just checked the TS config documentation. Seems that this config does not change the compilation result, so it does not affect library consumers. I think it's safe to change
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 it does do is negate any alerts TS would give about using too new API syntax.
Could an alternative be to do eg. cause in err
in the specific place instead?
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.
Second the @voxpelli suggestion
No. I have zero interest in supporting
Probably not, but I haven't actually clicked on the files tab yet. Personally, I don't like complicated test setups. I'd rather see all relevant details of the test inline with the test.
🤷♂️
That is reasonable. Such a PR should be a follow up after this is merged and released. |
…r with 2nd argument
According to code review by @jsumners Co-authored-by: James Sumners <james@sumners.email>
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 think the only thing missing at this point is the documentation.
You're right - I missed that there's a readme.md in this repo as well (and not just in pino's original repo). |
Co-authored-by: James Sumners <james@sumners.email>
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.
Looks good to me.
ping @mcollina |
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.
lgtm
closes #126
Open questions for this PR:
tsconfig.json
lib
config to supportnew Error(message, options)
(otherwise it only expects one argument). As far as I'm aware this does not break backwards compatibility since thetarget
did not change - but I may be wrong here. Thoughts?Thank you