I'm opening this here because it affects multiple packages, including mainly body-parser and Express, and I'd like to consolidate the discussion around qs instead of continuing it across multiple issues, discussions, and PRs.
Currently, the extended option brings in qs. That's not really a major problem, since we could simply make it an optional peer dependency and let users install it if they need it while continuing to provide the option.
The more important point is that, recently, we've been moving away from being opinionated about these kinds of things. For example, we've made the query parser customizable, and we're also working toward non-blocking JSON parsing by allowing custom parsers in body-parser (expressjs/body-parser#696). Similarly, raw-body no longer depends on iconv-lite; it now uses TextDecoder by default while still allowing users to provide their own decoder if needed stream-utils/raw-body#145.
Express already allows customizing the URL query parser, so for Express 6 I think we should remove the extended option entirely. That way, Express no longer has an opinion about which parser should be used. If the platform default isn't what you want, you can simply plug in your own parser, just as you already can today.
I'm marking this for discussion in a future meeting so we can get feedback from the rest of the team, especially the captains, and use it to help plan Express 6.
For ref: https://sourcegraph.com/search?q=context:global+count:1100000+%22set%28%27query+parser%27%2C+%27extended%27%22+-file:node_modules&patternType=keyword&sm=0
This isn't about the dependency tree or any of that. It's about reducing the maintenance burden and staying true to our philosophy of being unopinionated: use what the platform provides. 🙂
I'm opening this here because it affects multiple packages, including mainly
body-parserand Express, and I'd like to consolidate the discussion aroundqsinstead of continuing it across multiple issues, discussions, and PRs.qswithqs-esmorpicoquerybody-parser#566qsdependency express#6865Currently, the
extendedoption brings inqs. That's not really a major problem, since we could simply make it an optional peer dependency and let users install it if they need it while continuing to provide the option.The more important point is that, recently, we've been moving away from being opinionated about these kinds of things. For example, we've made the query parser customizable, and we're also working toward non-blocking JSON parsing by allowing custom parsers in
body-parser(expressjs/body-parser#696). Similarly,raw-bodyno longer depends oniconv-lite; it now usesTextDecoderby default while still allowing users to provide their own decoder if needed stream-utils/raw-body#145.Express already allows customizing the URL query parser, so for Express 6 I think we should remove the
extendedoption entirely. That way, Express no longer has an opinion about which parser should be used. If the platform default isn't what you want, you can simply plug in your own parser, just as you already can today.I'm marking this for discussion in a future meeting so we can get feedback from the rest of the team, especially the captains, and use it to help plan Express 6.
For ref: https://sourcegraph.com/search?q=context:global+count:1100000+%22set%28%27query+parser%27%2C+%27extended%27%22+-file:node_modules&patternType=keyword&sm=0
This isn't about the dependency tree or any of that. It's about reducing the maintenance burden and staying true to our philosophy of being unopinionated: use what the platform provides. 🙂