Open meilechwieder opened 3 years ago
As they should, since query strings in the browser (like the entire URL) is always and only a string.
The method is named "stringify" - do you expect something different?
I'm sorry but Qs.parse
usually parses Boolean strings to Boleans, and
Number strings to Numbers, just FYI
On Fri, Aug 27, 2021, 12:22 PM Jordan Harband @.***> wrote:
As they should, since query strings in the browser (like the entire URL) is always and only a string.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/ljharb/qs/issues/420#issuecomment-907321238, or unsubscribe https://github.com/notifications/unsubscribe-auth/AOS7IR44ZYYQKLGUHAT5PLLT663TRANCNFSM5C5MSKSQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
parse
is expected to produce something that's not a string, but stringify
is not.
Separately, qs.parse
does not in fact do that in my testing:
qs.parse('true') // { true: '' }
qs.parse('a=true') // { a: 'true' }
etc.
No tests here https://github.com/ljharb/qs/blob/bd9e3754d2871592baf42ca9fa988c2148a469a5/test/parse.js for false/true value.
@dmitry that's because parse
only accepts a string. Passing a boolean in is a type error, something that I'll probably make throw an exception in the next semver-major, whenever that is.
Regarding #91, a=true
in a query string is the string "true", not a boolean, so qs
won't ever do the wrong thing there by default. You'll have to use a custom decoder if you want nonstandard types.
Consider this code
true, false, 0, 1
all become strings