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

feat(serializers): Implemented "error with cause" serializer #130

Merged
merged 7 commits into from
Apr 9, 2023

Conversation

Yuval-Peled
Copy link
Contributor

  • 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.

closes #126

Open questions for this PR:

  • I did not implement support for VError style "cause", which is a function. Should we add a check for this specific use case? My gut says no, since this serializer is meant for native Errors with "cause", so we should not strive to support each "extended error" library.
  • The test file I added has a lot of duplication w.r.t the default error serializer test. Would it be better to have a single test file for both so that tests that are relevant for both can be configured to run once for each serializer?
  • I bumped the tsconfig.json lib config to support new Error(message, options) (otherwise it only expects one argument). As far as I'm aware this does not break backwards compatibility since the target did not change - but I may be wrong here. Thoughts?
  • This PR should be accompanied by a PR to the pino documentation so that pino users are aware this new serializer exists

Thank you

- 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
lib/err-helpers.js Outdated Show resolved Hide resolved
@Yuval-Peled
Copy link
Contributor Author

These tests fail for node v14. Working on a fix

@@ -1,7 +1,7 @@
{
"compilerOptions": {
"target": "es6",
"lib": [ "es2015" ],
"lib": [ "es2022" ],
Copy link
Contributor

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?

Copy link
Contributor Author

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.

Copy link
Contributor Author

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

Copy link
Contributor

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?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Second the @voxpelli suggestion

@jsumners
Copy link
Member

  • I did not implement support for VError style "cause", which is a function. Should we add a check for this specific use case?

No. I have zero interest in supporting VError. Let's standardize on the native object.

  • The test file I added has a lot of duplication w.r.t the default error serializer test. Would it be better to have a single test file for both so that tests that are relevant for both can be configured to run once for each serializer?

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.

  • I bumped the tsconfig.json lib config to support new Error(message, options) (otherwise it only expects one argument). As far as I'm aware this does not break backwards compatibility since the target did not change - but I may be wrong here. Thoughts?

🤷‍♂️

  • This PR should be accompanied by a PR to the pino documentation so that pino users are aware this new serializer exists

That is reasonable. Such a PR should be a follow up after this is merged and released.

lib/err.js Outdated Show resolved Hide resolved
test/err-with-cause.test.js Show resolved Hide resolved
lib/err-helpers.js Outdated Show resolved Hide resolved
lib/err-proto.js Outdated Show resolved Hide resolved
According to code review by @jsumners

Co-authored-by: James Sumners <james@sumners.email>
Copy link
Member

@jsumners jsumners left a 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.

@Yuval-Peled
Copy link
Contributor Author

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).
Will be done in a couple of minutes

Readme.md Outdated Show resolved Hide resolved
Co-authored-by: James Sumners <james@sumners.email>
Copy link
Member

@jsumners jsumners left a 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.

@jsumners jsumners requested a review from mcollina April 3, 2023 14:44
@jsumners
Copy link
Member

jsumners commented Apr 9, 2023

ping @mcollina

Copy link
Member

@mcollina mcollina left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm

@mcollina mcollina merged commit 0ccfa26 into pinojs:master Apr 9, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Discussion continuation: current design decision for error.cause is surprising and confusing
5 participants