feat: add new acceptNonStandardSearchParameters MockAgent option#4148
Merged
metcoder95 merged 1 commit intonodejs:mainfrom Apr 21, 2025
Merged
Conversation
dario-piotrowicz force-pushed the dario/multi-search-params-normalization branch 2 times, most recently from 97cee8d to 6d9cb9d Compare 
metcoder95 reviewed Apr 6, 2025
metcoder95 approved these changes Apr 6, 2025
mcollina reviewed Apr 7, 2025
metcoder95 reviewed Apr 8, 2025
metcoder95 approved these changes Apr 9, 2025
mcollina reviewed Apr 14, 2025
dario-piotrowicz force-pushed the dario/multi-search-params-normalization branch from cf7daab to 2eb2cb1 Compare 
Member
| Actually, can you add docs for this? |
Member Author
dario-piotrowicz force-pushed the dario/multi-search-params-normalization branch from 2eb2cb1 to c8abf9e Compare Member Author
| ok docs added 🙂 c8abf9e It was much quicker than I thought 😄, I was initially thinking of adding an example for this but it feels like a bit of an overkill to me right now 🤔, please let me know what you think 🙂 |
add a new `acceptNonStandardSearchParameters` option to make instances of `MockAgent` accept search parameters specified using non-standard syntaxes such as multi-value items specified with `[]` (e.g. `param[]=1¶m[]=2¶m[]=3`) and multi-value items which values are comma separated (e.g. `param=1,2,3`) Co-authored-by: Carlos Fuentes <me@metcoder.dev>
dario-piotrowicz force-pushed the dario/multi-search-params-normalization branch from c8abf9e to 36356b1 Compare dario-piotrowicz changed the title acceptNonStandardSearchParameters MockAgent option slagiewka pushed a commit to slagiewka/undici that referenced this pull request Feb 14, 2026
…odejs#4148) Co-authored-by: Carlos Fuentes <me@metcoder.dev>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Rationale
This PR adds a new
acceptNonStandardSearchParametersoption to makeinstances of
MockAgentaccept search parameters specifiedusing non-standard syntaxes such as multi-value items specified with
[](e.g.
param[]=1¶m[]=2¶m[]=3) and multi-value items which valuesare comma separated (e.g.
param=1,2,3)With these changes
MockAgentinstances can be enabled to intercept requestssuch as
https://example.com/qux-c?arraykey[]=a&arraykey[]=b, etc...Changes
MockAgents created with the
acceptNonStandardSearchParameters"normalize" requests such ashttps://example.com/qux-c?arraykey[]=a&arraykey[]=binto ones likehttps://example.com/qux-c?arraykey=a&arraykey=bso that they can then be handled normallyFeatures
N/A
Bug Fixes
Fixes #4146
Breaking Changes and Deprecations
None
Status
Note
My implementation supports the case of array values having
[](e.g.a[]=1,a[]=2,a[]=3) and also different array values separated by commas (e.g.a=1,2,3) and that's pretty much it, it could potentially support other syntaxes like the JSON API and Bitbucket API mentioned in https://medium.com/raml-api/arrays-in-query-params-33189628fa68, but that feels to me like quite an overkill right now. I am thinking that probably the cases I am adding support for now should cover most use cases anyways and if the extra ones will be needed in the future (someone opening an issue, etc...) they can always be incrementally added as needed on top of my changes 🤔