Allow qs parser to receive options

[iwaduarte]

My case is very trivial but it seems unsupported. I want to be able to separate between null and empty values.

What I would expect:

// qs library - https://github.com/ljharb/qs

var strictNull = qs.stringify({ a: null, b: '' }, { strictNullHandling: true });
var parsedStrictNull = qs.parse('a&b=', { strictNullHandling: true });

// results in :
assert.deepEqual(parsedStrictNull, { a: null, b: '' });

_// bodyParser (what would seem practical to implement) _
bodyParser.urlencoded({extended: true, {strictNullHandling: true }})

What do I have: Nothing likely is currently implemented.

I was digging through the library and I found several attempts to make the parser more configurable. Maybe it is time to have a flexible way of exploring your default (extended) parser ?

#46
#55

I could also provide a pull request. It seems to me that it is a straight-forward feature.

[dougwilson]

duplicate of #60 . If not, please let us know and we can always re-open.

[iwaduarte]

It is not. It's looks like. And I strongly disagree with your point mentioned in several of the issues.
You said something between the lines of "we could remove at anytime" but if you think about it. The need it is still there. People asking for it. And in 7 years time the library did not change that feature (removed the qs parser for a different one)

But also I fail to see if would be problematic to have this property enabled - { strictNullHandling: true }

[dougwilson]

Hi @iwaduarte I'm sorry you feel that way. Unfortunately that is the nature of modules: there are folks who run them and make decisions on what is and what is not part of it. This module is licensed under MIT and you are welcome to fork it if using the text parser + qs is not a workable solution for your use-case.

[dougwilson]

FWIW PR #282 implements the intended solution that would allow you to use any options anyone wants with qs or any other type of parser they want.