Repository navigation
fix(embed): scope cached includes to their page context - #2820
Conversation
|
Someone is attempting to deploy a commit to the Docsify Team on Vercel. A member of the Team first needs to authorize it. |
431a9b8 to
47ba462
Compare
cb56726 to
795936d
Compare
795936d to
4ecc34e
Compare
sy-records
left a comment
There was a problem hiding this comment.
I haven't been able to reproduce the issue. Could you set up a sandbox to help me reproduce it?
|
Thanks for checking, @sy-records. Here is a runnable StackBlitz reproduction. In the preview, click Run first → second → first. Both routes use byte-identical Markdown and different sibling
I built both Docsify bundles from those commits and reproduced the same result in Chromium, locally and in the StackBlitz preview. For local use, download the fixture ZIP, extract it, run |
|
Please use CodeSandbox; it seems your example is a usage issue. |
|
I added a minimal reproduction for the CodeSandbox request using default Docsify settings and ordinary hash links. Both Markdown pages use the documented code-include syntax and each has a different sibling Import To run the same fixture locally, download the ZIP, extract it, and run Chromium showed first → first → first on develop |
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
sy-records
left a comment
There was a problem hiding this comment.
OK, the reason it couldn't be reproduced earlier was because there was a hook.beforeEach . Now it can be reproduced.
There was a problem hiding this comment.
🟢 Approval recommended
The review identifies no active issues with the directory-scoped embed cache change.
No open issues 🎉
What changed in this PR
Fixes Docsify’s embed cache so pages with identical Markdown display relative includes from the correct content directory.
Changes:
- Scope cached tokens by resolved content directory and raw Markdown.
- Add unit coverage for cache reuse within a directory and separation across directories and content bases.
- Add a browser regression checking rendered snippets during first → second → first navigation.
| File | Description |
|---|---|
test/unit/embed-cache.test.js |
Verifies context-specific caching and reuse. |
test/e2e/embed.test.js |
Checks relative include content across page navigation. |
src/core/render/embed.js |
Keys cached tokens by content directory and Markdown. |
Review effort: Balanced



Summary
Pages in different directories can display the wrong embedded file when their Markdown is identical. For example, both
/first/and/second/can contain[snippet](snippet.js ':include :type=code'), while each directory has its ownsnippet.js. Visiting the first page and then the second currently keeps displaying the first directory's code.The prerender cache is keyed only by raw Markdown, even though relative include resolution depends on the content base and current route. Include those two values in the cache key. The browser regression navigates first → second → first and checks the actual rendered code each time.
Related issue, if any:
Reproduced on develop at
d823dbe51c1b2dea4c2091e2b952ded0d1e16616; no matching open fix found.What kind of change does this PR introduce?
For any code change,
Does this PR introduce a breaking change?
Validation
npm run test:e2e:chromium -- test/e2e/embed.test.js --workers=1 --reporter=line: passed.npm run test:jest -- --runInBand: 128 tests and 46 snapshots passed.npm run build,npm run lint,npm run typecheck, andgit diff --check: passed.Browser coverage: Chromium via Playwright; Firefox, WebKit, and unrelated E2E suites were not run locally.
Developed with assistance from OpenAI Codex; regression and fix validated locally.