Remove the `extended` option and stop being opinionated about parsers
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 25/100
Research direction
Start by reading Express's customizable query-parser behavior and the body-parser extended option, then review the linked body-parser and Express issues, discussions, and pull requests. The issue is marked for future team discussion, so completion depends on an agreed Express 6 plan for removing or replacing the option and updating the affected packages.
Written by the indexing model from the issue text.
Description
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.
- https://github.com/expressjs/body-parser/issues/252
- https://github.com/expressjs/body-parser/issues/566
- https://github.com/expressjs/body-parser/issues/347
- https://github.com/expressjs/body-parser/issues/132
- https://github.com/expressjs/body-parser/issues/22
- https://github.com/expressjs/body-parser/issues/88
- https://github.com/expressjs/express/pull/7151
- https://github.com/expressjs/express/pull/7117
- https://github.com/expressjs/express/pull/6865
- https://github.com/expressjs/express/issues/5878
- https://github.com/expressjs/express/discussions/5783
- https://github.com/expressjs/express/issues/6647
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 (https://github.com/expressjs/body-parser/pull/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 https://github.com/stream-utils/raw-body/pull/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.
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. 🙂
- Dominant language
- No language data
- Stars
- 73
- Forks
- 26
- Avg merge
- 5d 4h
- Merged PRs (30d)
- 1
Getting set up
- No Dockerfile or Docker Compose file
- No pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from expressjs/discussions
-
meeting
Difficulty 1/5 Under an hour Newbie friendliness 10/100
expressjs/discussions#527 ·
-
Difficulty 5/5 Over a week Newbie friendliness 25/100
expressjs/discussions#522 · 6 comments · 1 reaction ·
-
Server Fetch modeOpendiscuss
Difficulty 5/5 Over a week Newbie friendliness 25/100
expressjs/discussions#515 · 1 comment ·
-
tc agenda top priority
Difficulty 1/5 Under an hour Newbie friendliness 58/100
expressjs/discussions#512 · 2 reactions ·
-
meeting top priority
Difficulty 4/5 3-5 days Newbie friendliness 25/100
expressjs/discussions#507 · 3 reactions ·
All issues in expressjs/discussions
Similar issues
-
area/install-update comp/gateway P0 sweeper:risk-compatibility type/bug
Difficulty 2/5 Under an hour Newbie friendliness 72/100
NousResearch/hermes-agent#135997 · 3 comments ·
Maintainers usually reply within 1 day
-
Team: SCM
Difficulty 2/5 1-3 hours Newbie friendliness 66/100
microsoft/BCApps#12652 · 1 comment ·
Maintainers usually reply within 1 day
-
area:auth bug
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
ArchiveLabs/lenny#242 ·
Maintainers usually reply within 1 day