Investigate replacing qs
#5783
Replies: 26 comments 25 replies
-
|
It can't be done in Express 4; as you correctly noted, it would require a higher minimum version of Node. Express 5 will require a minimum of Node 18, and if a dependency is no longer required, I would rather just drop it. However, a significant perf difference could be a compelling enough reason to use it over built-ins. |
Beta Was this translation helpful? Give feedback.
-
|
Sounds good, do you want me to make a PR to use the built-in |
Beta Was this translation helpful? Give feedback.
-
|
@TheDevMinerTV if you want to make a PR targeting 5.x, that would be great |
Beta Was this translation helpful? Give feedback.
-
|
Will do ^^ |
Beta Was this translation helpful? Give feedback.
-
|
In #4990 it was suggested to replace
Does replacing both of them with |
Beta Was this translation helpful? Give feedback.
-
|
|
Beta Was this translation helpful? Give feedback.
-
|
your point is valid, but note that URLSearchParams is part of the URL spec, not ECMAScript
|
Beta Was this translation helpful? Give feedback.
-
|
Edit: Edit: This is very likely because the spec never mentions arrays. I'm not sure how to proceed here. Should we implement (or pull in a package for) the array parsing algorithm, if so, do we use the comma or the index syntax. Or should we drop the feature? IMO we should implement this ourselves with the index syntax. |
Beta Was this translation helpful? Give feedback.
-
|
sounds like we should continue to use |
Beta Was this translation helpful? Give feedback.
-
|
There seems to be |
Beta Was this translation helpful? Give feedback.
-
In the spirit of the very first line of your readme
I believe it would be great to provide a URLSearchParams based interface by default and offer pluggable support for qs or other parsers to allow users to decide for themselves without forcing qs on them. qs is quire large https://pkg-size.dev/qs and most applications today are just fine with using URLSearchParams on the server and client. It even has basic array support built in |
Beta Was this translation helpful? Give feedback.
-
There is a Completely removing |
Beta Was this translation helpful? Give feedback.
-
|
it probably does make sense that the query parser setting can be since then you can use whatever query parser you like by passing it in, without having to bloat express itself with such a library |
Beta Was this translation helpful? Give feedback.
-
|
Another option for 5.0 could be to make qs an optional peerDependency and users opting for the "extended" setting would have to install it manually. |
Beta Was this translation helpful? Give feedback.
-
|
Removing @ctcpip will |
Beta Was this translation helpful? Give feedback.
-
|
No, it will continue to be CJS-only |
Beta Was this translation helpful? Give feedback.
-
|
Alright, so it we'd have to use |
Beta Was this translation helpful? Give feedback.
This comment was marked as spam.
This comment was marked as spam.
-
It was an active choice to keep them separate (1.x cjs, 2.x esm - at the next breaking change, esm only) We will be backporting non breaking features and fixes to 1.x meanwhile |
Beta Was this translation helpful? Give feedback.
-
|
Faster-qs supports the requested feature https://github.com/hans00/faster-qs |
Beta Was this translation helpful? Give feedback.
-
|
I dont think we will be replacing this module, at least not any time soon. We are pushing to get v5 our the door and this is not on the list for that. Just want to temper folks expectations since the new group of maintainers, while no longer just one person, is still small and we have a lot of catch up we are doing. Additionally, with #5731 and v5 landing the default swap I would not be surprised if we went the path of removing all these as direct deps and go to them as 3rd party configuration additions instead for v6. Not promising anything, but also I don't want folks to waste a lot of time bikeshedding this issue for no reason. |
Beta Was this translation helpful? Give feedback.
-
|
I just made neoqs, fully backward compatible and forever going to follow I'd suggest URLSearchParams as the endgame, but in the meanwhile, neoqs could fill in the gap without being disruptive 😄 |
Beta Was this translation helpful? Give feedback.
-
|
I think the point I was trying to make above is that any movement on this at the moment is not something we are considering. Additional deps is not a concern we have (at least at the moment) and neither is performance (again, at least at this moment). Stability is the primary concern until we can get v5 shipped and v4 EOL'd. Once we have achieved those goals a lot more becomes viable for the project. If y'all are interested in helping us make those two goals happen first then please join the fun, we need all the help we can get. Until then though, I will be un-following this thread so I can stay focused on what is important for the ecosystem and Express community. |
Beta Was this translation helpful? Give feedback.
-
|
just an update, since v5 is now out and is the current version:
|
Beta Was this translation helpful? Give feedback.
-
|
hey folks. don't shoot the messenger here. you asked, I answered to the best of my understanding. the change to default to simple was made nearly 4 years ago. (but only released recently) AFAIK, removing qs was never discussed back then, so this doesn't seem like it was a completely deliberate decision to keep it around |
Beta Was this translation helpful? Give feedback.
-
|
ref: #3621 |
Beta Was this translation helpful? Give feedback.
-
|
i think it was a choice that could've been done in another, better way an optional peer would've been good. or drop it entirely because its a breaking change anyway there's not really any reason to keep it around as far as i can tell, either way. the only reason now seems to be that we can't drop it without a new major (but could've in this major) but it is what it is. in the next major, maybe there's chance we can do it in the way suggested here |
Beta Was this translation helpful? Give feedback.
-
|
To double down a bit on the "past decisions" bit here, we had nearly 10 years of backed-up work to look through. We chose the most impactful things to land and mostly left the rest as had been decided at in the past. Happy to see criticisms of those decisions, but I am not very partial to spending our (folks who are contributing to the project) time fielding requests/issues from folks who are neither contributors or users of Now, on to the more important topic: what is next for query parsing in I think we obviously need to land a parser type for The much more difficult question is if our users need a more feature rich query string parser. Historically they have, which is why Lacking any formal way to collect user feedback, I think that it will be tough to gauge impact without some real work doing outreach. Changing the status quo should take a bit more rigorous decision making than I have seen in this thread, and I am positive the current contributor team does not have the resources to do something like that. So the next best thing we can do is build a convincing case based on our own data. So far all of the data I see presented in this thread is using small details and missing the big picture. To build a convincing case, here are the things I would need to see:
I am also sure there are other things I am not thinking of that y'all are (or can with the right support) that we could do in this area. I suggest that nearly all of this is within scope of the Perf WG, so if y'all want to help us measure install time, or startup time, or whatever other measure please join our effort over there. |
Beta Was this translation helpful? Give feedback.
-
|
I'm not sure we should even be focusing on the performance yet We currently pull in an opinionated dependency for something which isn't enabled by default. If the community starts upgrading express everywhere, presumably this will lead to a decline of people using qs (we will only know by doing the upgrades though over time). If that's the case, it means all those projects have a dead dependency nothing actually uses. Long before we consider performance, I think we need to think about that. You're asking for someone to benchmark the project with and without it. Isn't it pretty much impossible that a piece of code loading a module is faster than one that doesn't? I think the important thing is we're comparing against not having it at all. Not against another library. Any project without the dependency will of course be faster to install and run than one with it (even if it is milliseconds of time). I'm going to try get the e18e community to start an effort to upgrade express throughout the ecosystem. If that gets going, we should see the problem become more and more obvious as an increasing amount of projects stop using qs. |
Beta Was this translation helpful? Give feedback.
-
|
i believe the way forward is that express no longer ships any query string parser. it defaults to the built in one, and it allows you to pass in your own if you want any more than that. in many projects, qs is no longer the appropriate choice. many will not use nesting, many want a faster parser, many just have a different preference. we already made one good step forward by defaulting to we're likely to move many projects off this is before considering any performance differences, of which there are many. many projects can see perf gains by using a different library, or no library at all. many don't need nesting at all. the choice is there at least, but we're still forced to install something we don't use or want. |
Beta Was this translation helpful? Give feedback.
-
|
personally, I am more convinced by the argument to remove it, than I am by the original argument to replace it with something else |
Beta Was this translation helpful? Give feedback.
-
|
100% - its very easy to bring your own parser if you need anything node itself doesn't provide we don't need to have an opinionated choice anymore i think |
Beta Was this translation helpful? Give feedback.
-
|
some hard data -- express v5 still has but a fraction of usage compared to v4, but we can already see in the wild a ton of deliberate opting in to extended query parsing: |
Beta Was this translation helpful? Give feedback.
-
|
Very true - but the download numbers indicate the current upper limit of that upgrade effort, which your efforts certainly may shift. |
Beta Was this translation helpful? Give feedback.
-
|
Indeed, I'm confident the downloads and usages will be a different picture when we're further into the upgrade. Also let's not forget the default is to use the built in parser. People turning the extended one on is meaningless in much of this discussion. If the extended flag didn't exist - they would install a package and pass that in just the same. Which is what we're asking for How many people turn extended mode on doesn't tell us how many people want a built in parser to do that. |
Beta Was this translation helpful? Give feedback.
-
|
I think that query is over-counting quite a bit. For example, it's returning results that specifically switch away from extended query parser: 
It's probably desirable to wrap it in quotes, which returns a smaller set of results: |
Beta Was this translation helpful? Give feedback.
-
|
Actually, I just noticed that it looks like most of the results are from people checking in their |
Beta Was this translation helpful? Give feedback.
-
|
yep, thanks for catching that! |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Pros
qs) vs. ~30 kB (fast-querystring)qs's subdeps have a lot of recursion in require cycles as wellexpress(if there's platform that allowsexpressto be used, at least)Cons
fast-querystringrequires at least Node 8:fast-querystringdoesn't support setting prototypesNotes
benchmarkfolder in this repo and just replacing therequirecall tofast-querystringon a idling 7950X running Node v8.17.0URLSearchParamswhich has been supported since Node 10URLSearchParamsto be pretty slow, though, this needs to be benchmarked firstBeta Was this translation helpful? Give feedback.
All reactions