Pass custom parameters to `qs`

[AllanJard]

This is really the same as #98 but that issue has been locked. The original rational for not adding the ability to pass configuration parameters to qs was that package was abandoned. That is no longer the case and qs is now actively maintained. As such, I wonder if we might be able to revisit the original request and decision as that ability would be really useful.

Also released is #203 requesting support for custom parsers. That issue is perhaps less important since qs is maintained again?

The reason I'd like to see this, is that if I submit something like l-2[].dp-1 then the parameter in req.body is always l-2 regardless of what follows the []. (I think the same applies with just a .) due to the lack of support being able to set allowDots in qs.

[NakajimaTakuya]

I agree with him.
And in any case, I want to solve this problem as soon as possible, so I will fork body-parser in the meantime.
For future compatibility, I am curious to see if the library will take the generic parser as a solution or reorient itself in response to #453.
I would like to hear your thoughts once again.

[jybleau]

I created a fork that uses a new parameter: extendedOptions
https://github.com/jybleau/body-parser

Could or shoud it be considered as a PR?

I had parsing inconsistencies when using with Datatables Editor until I found out is was something that could be configured using qs options.

For instance, DT Editor by default uses an id, which is usually an integer, to identify objects and because of default array options in qs:

• Sending this query string: data[2][name]=joe, results in: data: [{name: "joe"}] (data is an array)

But with a higher id number:

• Sending this query string data[101][name]=joe2 results in: data: {"101": { name: "joe2" }} (data is now an object)

So it can result in an array or a plain object depending on the value of the number because the default limit for parsing an array is 100; above that threshold, it's parsed to an object.

In this case it's preferable to set qs not to parse arrays or have the array limit to 0.
So, would be nice to expose "advanced" qs options.

[jybleau]

@dougwilson, have there been any new thoughts on the idea of passing parameters to qs? Or should we still wait for a next major release for a new approach on this parsing "issue", so to speak.
Thanks !

[jybleau]

Since the urlEncoded parser now relies solely on qs, and both the extended and depth options directly reference the qs documentation, would it make sense to start exposing more qs options?

Alternatively, what about adding an extendedOptions property that could be passed directly to the qs parser?

Or maybe it’s still too early for that?

Happy to open a PR if it seems worthwhile.