fix(utils): resolve site-relative paths in the eager Git VCS - #12329
fix(utils): resolve site-relative paths in the eager Git VCS#12329alexandrosang21 wants to merge 1 commit into
Conversation
The eager strategy keys its file map by absolute paths, but looks up whatever path it is handed. RouteMetadata.sourceFilePath is documented as relative to the site directory, and the sitemap plugin forwards it unchanged, so the lookup missed and returned null. The result was a silently missing <lastmod> in sitemap.xml under experimental_vcs: 'default-v2', which selects the eager strategy in production. 'git-ad-hoc' and 'default-v1' were unaffected because they shell out to git log, which resolves relative paths itself. Resolves the path against the site dir when it is not already absolute. Every existing eager test passed an absolute path, which is why this was not caught.
|
Hi @alexandrosang21! Thank you for your pull request and welcome to our community. Action RequiredIn order to merge any pull request (code, docs, etc.), we require contributors to sign our Contributor License Agreement, and we don't seem to have one on file for you. ProcessIn order for us to review and merge your suggested changes, please sign at https://code.facebook.com/cla. If you are contributing on behalf of someone else (eg your employer), the individual CLA may not be sufficient and your employer may need to sign the corporate CLA. Once the CLA is signed, our tooling will perform checks and validations. Afterwards, the pull request will be tagged with If you have received this in error or have any questions, please contact us at cla@meta.com. Thanks! |
✅ [V2]Built without sensitive environment variables
To edit notification comments on pull requests, go to your Netlify project configuration. |
|
Thank you for signing our Contributor License Agreement. We can now accept your code for this (and any) Meta Open Source project. Thanks! |
Pre-flight checklist
<lastmod>is omitted with experimental_vcs: 'default-v2' in Docusaurus 3.10.2 #12322) and the maintainers have approved on my working plan.Motivation
Fixes #12322. With
future.experimental_vcs: 'default-v2',sitemap.xmlis generated withoutany
<lastmod>values, while'git-ad-hoc'and'default-v1'produce them correctly for thesame site and Git history.
default-v2selects the eager Git strategy in production.vcsGitEagerkeys its file map byabsolute paths:
but the lookup uses whatever path it is handed:
The sitemap plugin passes
route.metadata.sourceFilePath, whichRouteMetadatadocuments as"expected to be relative to the site directory". So the lookup misses and returns
null, andgetRouteLastmoddrops<lastmod>for that route without any warning.git-ad-hocanddefault-v1are unaffected because they shell out togit log -- <path>, whichresolves a relative path itself.
This resolves the path against the site dir when it is not already absolute. Absolute paths keep
working unchanged, so
getFileCreationInfoand existing callers are unaffected.Test Plan
Unit test. Added
can read repo file info from a site-relative pathto the existingVSC Git Eager Strategyblock. It fails onmainand passes with this change. Every existingeager test passes an absolute path via
path.join(repoDir, ...), which is why this gap was notcovered.
eslint,tsc --noEmit,oxfmt --list-differentandcspellare all clean on the two changedfiles.
End to end, using the reproduction repository from the issue
(eMUQI/docusaurus-vcs-sitemap-repro),
building the same site twice with only this patch differing:
@docusaurus/utils<url><lastmod>Its
npm run verify:reproasserts thatdefault-v2produces zero<lastmod>, so with the fixapplied that assertion now fails, which is the intended outcome.
Test links
Not applicable: this changes build-time sitemap metadata rather than anything rendered, so there
is no UI to preview.
Disclosure
This change was written with AI assistance (Claude), per the AI policy in CONTRIBUTING.md. I have
reviewed every line, verified the root cause against the reproduction repository above, and can
explain and defend the change in review.