Skip to content

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
quartz-community:mainfrom
KinnariyaMamaTanha:fix/bump-utils-decode-cjk-slug
Open

fix(graph): bump @quartz-community/utils to ^0.1.1 to fix local graph on non-ASCII slugs#12
KinnariyaMamaTanha wants to merge 1 commit into
quartz-community:mainfrom
KinnariyaMamaTanha:fix/bump-utils-decode-cjk-slug

Conversation

@KinnariyaMamaTanha

Copy link
Copy Markdown

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 from getFullSlugFromUrl(), which reads window.location.pathname. The browser keeps that percent-encoded for non-ASCII paths (e.g. 杂/foo arrives as %E6%9D%82/foo), so the seed slug never matches the already-decoded keys in contentIndex.json. The BFS finds no neighbours and the local graph collapses to a single dot. The global graph escapes this because it uses depth: -1 and 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") — getFullSlugFromUrl now returns decodeURI(window.location.pathname). The only reason it isn't reaching users is that this plugin's package-lock.json still pins utils to 0.1.0, so npm ci / a fresh clone keeps building against the un-decoded version. #10 spotted this exact gap.

So rather than adding another decodeURIComponent in 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.1
  • package-lock.json: refreshed so utils resolves to 0.1.1

No source changes. dist/ is gitignored and rebuilt by CI, so once the lock points at 0.1.1 the emitted bundle's getFullSlugFromUrl becomes decodeURI(window.location.pathname) on its own.

Verification

With this change, a clean npm install --ignore-scripts && npm run build:

  • dist/index.js and dist/components/index.js now contain decodeURI(window.location.pathname) (was the raw window.location.pathname)
  • the local graph renders the full neighbourhood again on CJK pages
  • existing vitest suite 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.

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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant