fix(NODE-7436): EJSON.stringify type signature#870
fix(NODE-7436): EJSON.stringify type signature#870chdanielmueller wants to merge 7 commits intomongodb:mainfrom
Conversation
|
@chdanielmueller , thanks so much for your contribution! The team is going to prioritize this PR and NODE-7436 at our next triage session. |
tadjik1
left a comment
There was a problem hiding this comment.
hi @chdanielmueller, thanks a lot for the contribution. The bug is real, well-documented, and the test coverage you added is great.
The core issue is that space = 0 discards the user's space value when options are passed in the replacer position.
However, the fix is significantly more complex than it needs to be. The entire bug can be fixed by deleting one line (space = 0). The existing code already treats any non-array object in replacer position as options.
I would suggest minimal fix:
if (replacer != null && typeof replacer === 'object' && !Array.isArray(replacer)) {
options = replacer;
replacer = undefined;
- space = 0
}The overloads, type guard, and restructured function body are unnecessary for this fix and introduce maintenance overhead.
src/extended_json.ts
Outdated
| } | ||
|
|
||
| // Check that there are no invalid properties (only known EJSON serialize options) | ||
| const validKeys = ['legacy', 'relaxed', 'ignoreUndefined']; |
There was a problem hiding this comment.
This creates a maintenance footgun with to compiler warning to catch if EJSONSerializeOptions gains a new property, or if detection silently breaks. In this case the new property would be treated as a replacer and passed into JSON.stringify.
src/extended_json.ts
Outdated
| if ('legacy' in value && typeof value.legacy !== 'boolean') { | ||
| return false; | ||
| } | ||
| if ('relaxed' in value && typeof value.relaxed !== 'boolean') { | ||
| return false; | ||
| } | ||
| if ('ignoreUndefined' in value && typeof value.ignoreUndefined !== 'boolean') { | ||
| return false; | ||
| } |
There was a problem hiding this comment.
The strict key check causes silent misbehavior on typos. If something like {relaxd: false} will be passed - this guard returns false and the object will silently be forwarded to JSON.stringify as a replacer - producing wrong output, the existing typeof replacer === 'object' && !Array.isArray(replacer) would correctly treat it as options. This is more forgiving and safer.
There was a problem hiding this comment.
That's a great catch. I did not think of that.
I simplified the type guard to the old implementation.
I added a new test to validate the behavior in the presence of typos and to ensure this decision is explicitly captured.
see d3047c3
| if (isEJSONSerializeOptions(replacerOrOptions)) { | ||
| options = replacerOrOptions; | ||
| replacer = undefined; | ||
| space = 0; |
There was a problem hiding this comment.
I think this is the original bug and removing just this line (avoid unconditional discarding the space value( would make everything work as expected.
There was a problem hiding this comment.
Whilst I think, that my approach would have improved readability for the next developer I see your concern.
I did revert the implementation to the previous implementation but kept the new variable names as an indicator that it can be either or.
ee14858
| * console.log(EJSON.stringify(doc, { relaxed: false }, 2)); | ||
| * ``` | ||
| */ | ||
| function stringify( |
There was a problem hiding this comment.
These overloads add type-level documentation of supported call patterns, but they also add maintenance hurdle. Since the runtime checks are needed regardless, and the existing signature with the union type already communicates that options can go in the second position - this doesn't provide enough value to justify the complexity.
There was a problem hiding this comment.
I appreciate the concern about complexity. From my perspective, the overloads provide meaningful value: they catch invalid parameter combinations (e.g., passing space before options when replacer is omitted) at compile-time and make IDE autocomplete show three clear patterns instead of a confusing union type.
In my opinion the ~15 lines of declarations add negligible maintenance cost while significantly improving type safety and DX.
There was a problem hiding this comment.
Pull request overview
This PR updates EJSON.stringify to support additional call signatures (notably (value, options, space)), aligning its ergonomics more closely with JSON.stringify, and adds tests to validate supported overload combinations.
Changes:
- Added overloads and new runtime argument-disambiguation logic for
EJSON.stringify. - Introduced an internal type guard used to distinguish
optionsfromreplacer/space. - Added a new test suite covering many parameter signature combinations.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
src/extended_json.ts |
Adds overloads and new argument parsing for EJSON.stringify via an internal options type guard. |
test/node/extended_json.test.ts |
Adds test coverage for supported EJSON.stringify parameter combinations. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
|
Hi @tadjik1 |
|
hi @chdanielmueller, thanks a lot for updating PR 👍 Just wanted to confirm that this work is not lost, and it's tracked. I will re-review changes as soon as possible. |
Description
Summary of Changes
This pull request enhances the flexibility and robustness of the
EJSON.stringifyfunction by supporting multiple parameter signature combinations, similar toJSON.stringify.It introduces a new internal type guard to accurately distinguish between options and replacer parameters, and adds comprehensive tests to ensure correct behavior across all supported overloads.
It supports a previously advertised function signature which was not implemented.
EJSON.stringify(object, { relaxed: false }, 2)Notes for Reviewers
The tests should contain every previously possible and also previously advertised but not working combination of inputs.
The changes within the function have to do with the previous typescript signature which has been used but did not work. See
js-bson/test/bench/etc/generate_documents.ts
Line 27 in 0712bb1
Off Topic: Documented within NODE-7437
Release Highlight
Release notes highlight
Double check the following
npm run check:lint)type(NODE-xxxx)[!]: descriptionfeat(NODE-1234)!: rewriting everything in coffeescript