Pass custom parameters to `qs`

[AllanJard]

Pass custom parameters to `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]

@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]

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.