fix(utils.url): keep the hash out of the query in withQuery - #615
Open
vidigoat wants to merge 1 commit into
Open
fix(utils.url): keep the hash out of the query in withQuery#615vidigoat wants to merge 1 commit into
withQuery#615vidigoat wants to merge 1 commit into
Conversation
The hash is the last component of a URL, so query parameters have to be inserted before it. `withQuery` did not account for it, which either dropped the added parameters into the fragment or folded the fragment into an existing parameter's value.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (2)
📝 WalkthroughWalkthrough
ChangesURL Fragment Preservation
Estimated code review effort: 2 (Simple) | ~10 minutes 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
withQuerytreats the whole input aspath[?query], so a URL that carries a fragment ends up mangled. The hash is the last component of a URL, so the query has to be spliced in before it.There are two failure modes, both reachable through
$fetchsincefetch.tscallswithQuery(context.request, context.options.query)for any string request:When the URL has no
?, the added parameters are appended after the#and become part of the fragment, so they are never sent. When the URL already has a?, everything after it (including the fragment) is parsed as the query string, so the last existing parameter's value silently absorbs#sectionas%23section.This is a regression against v1, which used
ufo'swithQuery. Minimal reproduction against the published packages:The fix splits the fragment off before touching the query and re-appends it at the end. I checked the patched
withQueryagainstufo@1.6.4over the hash edge cases (no hash, empty hash, hash before/after an existing query, hash-only input, query that resolves to empty) and the output matches.The regression test goes through the existing
/echoroute, which reportspathname + search, so it asserts what the server actually receives rather than what the helper returns; the last assertion uses anonResponsehook to check that the fragment itself survives in the final request URL. It fails onmainwithexpected '/echo' to equal '/echo?foo=1'.pnpm lintandvitest runboth passSummary by CodeRabbit
Bug Fixes
Tests