Inconsistency with valueless keys

[ljharb]

Inconsistency with valueless keys

[nlf]

This is clearly documented in the readme.

Empty strings and null values will omit the value, but the equals sign (=) remains in place:

Qs.stringify({ a: '' });
// 'a='

Qs.parse('a'); results in { a: '' } so your re-stringified object gets the = added to it. It could be changed, though if there's some consensus that omitting the = is the desired behavior.

[neverfox]

I think you misunderstand the reason why I posted the issue. It's not that I'm surprised by the behavior of stringify given the output of parse. Rather, I'm surprised by the fact that stringify doesn't perfectly reverse the result of parse in these cases. I also understood, going into writing the issue, why it's happening, i.e. the fact that parse gives '' for those valueless keys. The problem is that it happens at all, under the assumption that the assertion above is an important one.

I'm not sure what a good solution is since it's reasonable to expect that a= should parse to either null or ''. There's also a case to be made that { a: null } and { a: '' } should stringify to a=. But there are APIs out there that expect no = to work correctly, and there's currently no way to stringify a query object using qs to get what they require (if there was, then you could have parse produce that instead, and all would be well). An option might be worth considering but that doesn't help when using popular packages like node-request, which in turn use qs (unless they open up their API to allow you to configure qs.

Basically, I'm trying to use the following composition of requests:

//requests using baseRequest() will set the 'x-token' header
var baseRequest = request.defaults({
  uri: 'http://someapi.com'
  qs: {
    foo: '', // won't work because of how qs.stringify works
    bar: 1
  }
})

//requests using specialRequest() will include the qs set in
//baseRequest and will also include additional parameters
var specialRequest = baseRequest.defaults({
  qs: {
    baz: 1
  }
})

While I could manually add the query string:

//requests using baseRequest() will set the 'x-token' header
var baseRequest = request.defaults({
  uri: 'http://someapi.com?foo&bar=1'
})

I cannot extend it:

//requests using specialRequest() will include the qs set in
//baseRequest and will also include additional parameters
var specialRequest = baseRequest.defaults({
  qs: {
    baz: 1
  }
})

The problem is that this essentially results in a qs.stringify(qs.parse(url.parse(url).query)) and the url of specialRequest is now incorrect. However, I think one should expect qs.stringify(qs.parse(url.parse(uri).query)) not to cause a problem under any circumstances.

[nlf]

While I agree with you in principle, there are other conversions that cause qs.stringify(qs.parse(url.parse(uri).query)) to return an altered string. Arrays being one of them.

I'll look in to adding an option to omit the = when stringifying if the value is null or ''. I'm not comfortable changing the default without a consensus from other users, however, so that does mean that pull requests will have to be made to other libraries that rely on qs to make sure that they allow sending options where relevant.

[nlf]

There's an option to omit the = for null values now, see #85. closing this