fix(graph): bump @quartz-community/utils to ^0.1.1 to fix local graph on non-ASCII slugs - #12
Open
KinnariyaMamaTanha wants to merge 1 commit into
Conversation
The local graph collapses to a single node on pages with non-ASCII (e.g. CJK) slugs. getSlugFromUrl() seeds the neighbourhood BFS from getFullSlugFromUrl(), which reads window.location.pathname. Browsers keep that percent-encoded for non-ASCII paths, so the seed slug never matches the decoded keys in contentIndex.json and the BFS finds no neighbours. The global graph is unaffected because it uses depth -1. utils 0.1.1 already fixes this at the source by decoding the pathname (commit d16d8d9, "fix: decode URI in getFullSlugFromUrl for non-ASCII slugs"), but the graph plugin's lockfile still pins utils 0.1.0, so fresh installs keep pulling the un-decoded version. Bumping the range to ^0.1.1 and refreshing the lockfile lets the plugin consume the released fix. No graph source changes needed: the built bundle's getFullSlugFromUrl becomes decodeURI(window.location.pathname) and the local graph renders the full neighbourhood again. Refs quartz-community#10.
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.
Hi! Thanks for maintaining this plugin. 👋
This is a small follow-up to #10, which already did a great job pinning down why the local graph breaks on non-ASCII (e.g. CJK) slugs. I hit the same thing on a Quartz v5 site with Chinese page paths — the little inline graph only ever shows the current node, while the full-screen graph is fine.
What's happening
getSlugFromUrl()seeds the neighbourhood BFS fromgetFullSlugFromUrl(), which readswindow.location.pathname. The browser keeps that percent-encoded for non-ASCII paths (e.g.杂/fooarrives as%E6%9D%82/foo), so the seed slug never matches the already-decoded keys incontentIndex.json. The BFS finds no neighbours and the local graph collapses to a single dot. The global graph escapes this because it usesdepth: -1and just adds every node regardless of the seed.Why this PR instead of another source patch
You already fixed this upstream in
@quartz-community/utils@0.1.1(d16d8d9, "decode URI in getFullSlugFromUrl for non-ASCII slugs") —getFullSlugFromUrlnow returnsdecodeURI(window.location.pathname). The only reason it isn't reaching users is that this plugin'spackage-lock.jsonstill pins utils to0.1.0, sonpm ci/ a fresh clone keeps building against the un-decoded version. #10 spotted this exact gap.So rather than adding another
decodeURIComponentin the graph source (as in #5 / #7 / #11), this PR just lets the plugin pick up your released fix:package.json:@quartz-community/utils^0.1.0→^0.1.1package-lock.json: refreshed so utils resolves to0.1.1No source changes.
dist/is gitignored and rebuilt by CI, so once the lock points at 0.1.1 the emitted bundle'sgetFullSlugFromUrlbecomesdecodeURI(window.location.pathname)on its own.Verification
With this change, a clean
npm install --ignore-scripts && npm run build:dist/index.jsanddist/components/index.jsnow containdecodeURI(window.location.pathname)(was the rawwindow.location.pathname)vitestsuite still passes (4/4)If you'd prefer to also guard against a future re-lock drifting back to 0.1.0, happy to adjust the range further or add a changeset — just let me know what fits your release flow. Thanks again!
Refs #10.