By switching to picoquery, we can gain a substantial perf boost (it is much faster than qs, and about the same speed as fast-querystring). It is based on fast-querystring, but with support for nesting.
The behaviour will slightly change here in that pq is stricter with syntax than qs. For example, it makes no sense to mix these two syntaxes: foo=1&foo=2&foo[]=3. qs supports this at the cost of speed, while pq requires you to choose one.
If you don't yet want to change this behaviour, there is another PR moving to neoqs instead. That will keep the same interface and behaviour with a much smaller change in performance.
By switching to picoquery, we can gain a substantial perf boost (it is much faster than qs, and about the same speed as
fast-querystring). It is based onfast-querystring, but with support for nesting.Similarly, we can drop a few dependencies.
Note that this is part of the ongoing ecosystem-cleanup.
Important note:
The behaviour will slightly change here in that pq is stricter with syntax than qs. For example, it makes no sense to mix these two syntaxes:
foo=1&foo=2&foo[]=3. qs supports this at the cost of speed, while pq requires you to choose one.If you don't yet want to change this behaviour, there is another PR moving to
neoqsinstead. That will keep the same interface and behaviour with a much smaller change in performance.let me know and i'm happy to work with either!