Closed aks- closed 6 months ago
@ljharb qs.stringify({ foo: [], bar: 'baz' }, { allowEmptyArrays: true })
produces foo[]&bar=baz
. But I am wondering if you need { allowEmptyArrays: true }
when parsing because one can argue if the string has foo[]
that means we want to be able to parse it to original object that was handed to qs.stringify
. What do you think about dropping allowEmptyArrays
option from the qs.parse
?
Current behaviour is qs.parse('foo[]&bar=baz')
-> { foo: [ '' ], bar: 'baz' }
. After the above change it would produce { foo: [], bar: 'baz' }
. I would guess that would be a breaking change where ''
(empty string) is dropped?
Yes, that would be a breaking change, and it’s important that things round trip - so i think we do need the option in both.
All modified and coverable lines are covered by tests :white_check_mark:
Comparison is base (
04f422f
) 99.80% compared to head (f22b2bc
) 99.81%.
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
@ljharb any ETA to release a new version containing these changes?
@konnng-dev there's a few open PRs i want to land first
Needs adding to the typescript definitions
Object literal may only specify known properties, and 'allowEmptyArrays' does not exist in type 'IStringifyOptions'.
This PR adds
allowEmptyArrays
option which let's you keep empty arrays in the object values and address this issueWithout
allowEmptyArrays
optionWith
allowEmptyArrays
options set to true