Resolve leading-/ include paths against the project root (bd-w9koo1i2) - #468
Merged
Conversation
{{< include /path/from/root.qmd >}} was handed to the filesystem as an
OS-absolute path: Path::join discards its base when the right-hand side
is absolute, so the Quarto convention that a leading `/` means
project-root-relative (Q1 resolvePath, glob decision D2) never applied
and every such include failed with Q-17-2. Found porting the
posit-connect docs to Quarto 2.
- include_expansion.rs: new resolve_include_target() anchors leading-/
(or Windows-authored \) paths at ctx.project.dir — which already
matches Q1's anchor in both modes (project root, or the input file's
directory for single-file renders) — and everything else at the
including file's directory, unchanged. The root anchor stays fixed at
every nesting level.
- quarto-preview deps.rs: extract_include_deps mirrors the same rule;
a leading-/ include previously fell through normalize_forward_slash's
RootDir fallback and never matched the SPA's project-relative paths,
so editing the included file did not re-render the includer.
- Tests: 5 new integration tests (ProjectContext::discover-based
harness: project mode, cross-tree target, single-file parity, nested
leading-/, relative regression guard), 4 unit tests for the helper,
1 preview deps test. The leading-/ tests failed with Q-17-2 pre-fix.
- docs/errors/include/Q-17-2.qmd documented the old behavior ("not the
project root"); now describes both anchors.
Plan: claude-notes/plans/2026-08-07-include-project-absolute-paths.md
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
✅ Snyk checks have passed. No issues have been found so far.
💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse. |
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.
Summary
{{< include /admin/_includes/license-file.qmd >}}failed with Q-17-2: the leading-/path was handed to the filesystem as an OS-absolute path. Per the Quarto path convention (Q1'sresolvePathincore/handlers/base.ts, q2's own glob decision D2), a leading/is project-root-relative. Found porting the posit-connect docs to Quarto 2.The defect:
base_dir.join(&include_path)—Path::joindiscards its base when the right-hand side is absolute.Changes
include_expansion.rs: newresolve_include_target()anchors leading-/(or Windows-authored\) paths atctx.project.dir; everything else resolves against the including file's directory, unchanged.ProjectContext.diralready matches Q1's anchor in both modes (project root, or the input file's directory for single-file renders), so no mode branch is needed. The root anchor stays fixed at every include-nesting level. Also fixes the same class of failure in the WASM/hub-client build, where a leading-/path escaped the/project/VFS root.quarto-preview/deps.rs:extract_include_depsmirrors the same anchors — previously a leading-/include never matched the SPA's project-relative dep strings, so editing the included file didn't re-render the includer inq2 preview.docs/errors/include/Q-17-2.qmd: documented the old behavior ("not the project root"); now describes both anchors.Tests (TDD)
include_project_absolute.rs) driving the real HTML pipeline throughProjectContext::discoveron temp-dir layouts: project mode, cross-tree target, single-file parity, nested leading-/, relative regression guard. The four leading-/tests failed with Q-17-2 before the fix.resolve_include_target; 1 preview deps unit test (failed pre-fix returning the raw absolute path).cargo xtask verify(including WASM + hub-client legs) green.End-to-end verification
q2 rendernow emits no warnings and the renderedsub/doc.htmlcontains the included marker (inspected).admin/licensing/index.html, one per former warning site.Plan:
claude-notes/plans/2026-08-07-include-project-absolute-paths.mdStrand: bd-w9koo1i2 (docs follow-up filed as bd-ehp5ardt)
🤖 Generated with Claude Code