Summary Found a subtle issue with pathing trying to add custom stylesheet.
Claude helped me figure out the issue. This is the writeup below:
Related issue: #397 (WSL stylesheet path failure — same root cause)
What to change
Three files need identical treatment. In each getCssUriStrings(), replace the bare spread of user paths with a map that auto-prefixes bare absolute paths:
Files:
src/renderers/html-renderer-markdown.ts
src/renderers/html-renderer-plaintext.ts
src/renderers/html-renderer-sourcecode.ts
The change in each file (same pattern everywhere):
// Before
const userSuppliedCssUrls: string[] = markdownConfig.get("stylesheets") ?? [];
return [
"bundled/default-markdown.css",
...
...userSuppliedCssUrls, // ← bare paths passed through
"bundled/settings.css"
];
// After
import * as path from "path";
const userSuppliedCssUrls: string[] = markdownConfig.get("stylesheets") ?? [];
const routedCssUrls = userSuppliedCssUrls.map(p =>
path.isAbsolute(p) && !p.startsWith("absolute/") ? absolute/${p} : p
);
return [
"bundled/default-markdown.css",
...
...routedCssUrls,
"bundled/settings.css"
];
Why this is safe:
path.isAbsolute() correctly handles both macOS/Linux (/foo) and Windows (C:\foo)
The absolute/ route already exists and works — we're just wiring up to it automatically
Paths that already have absolute/ or workspace.resource/ or http(s):// prefixes are left untouched
No behavior change for relative paths or already-correct paths
Also worth adding (optional but good)
A note to package.nls.json / README clarifying that bare absolute paths now work, and that absolute/ prefix is no longer required (but still accepted for backwards compatibility).
PR description angle
Reference issue #397, mention this affects macOS, Linux, and WSL users who naturally type absolute paths. The fix is minimal — 3 files, ~3 lines each, no new routing logic needed since the server side already handles it correctly.
Summary Found a subtle issue with pathing trying to add custom stylesheet.
Claude helped me figure out the issue. This is the writeup below:
Related issue: #397 (WSL stylesheet path failure — same root cause)
What to change
Three files need identical treatment. In each getCssUriStrings(), replace the bare spread of user paths with a map that auto-prefixes bare absolute paths:
Files:
src/renderers/html-renderer-markdown.ts
src/renderers/html-renderer-plaintext.ts
src/renderers/html-renderer-sourcecode.ts
The change in each file (same pattern everywhere):
// Before
const userSuppliedCssUrls: string[] = markdownConfig.get("stylesheets") ?? [];
return [
"bundled/default-markdown.css",
...
...userSuppliedCssUrls, // ← bare paths passed through
"bundled/settings.css"
];
// After
import * as path from "path";
const userSuppliedCssUrls: string[] = markdownConfig.get("stylesheets") ?? [];
const routedCssUrls = userSuppliedCssUrls.map(p =>
path.isAbsolute(p) && !p.startsWith("absolute/") ?
absolute/${p}: p);
return [
"bundled/default-markdown.css",
...
...routedCssUrls,
"bundled/settings.css"
];
Why this is safe:
path.isAbsolute() correctly handles both macOS/Linux (/foo) and Windows (C:\foo)
The absolute/ route already exists and works — we're just wiring up to it automatically
Paths that already have absolute/ or workspace.resource/ or http(s):// prefixes are left untouched
No behavior change for relative paths or already-correct paths
Also worth adding (optional but good)
A note to package.nls.json / README clarifying that bare absolute paths now work, and that absolute/ prefix is no longer required (but still accepted for backwards compatibility).
PR description angle
Reference issue #397, mention this affects macOS, Linux, and WSL users who naturally type absolute paths. The fix is minimal — 3 files, ~3 lines each, no new routing logic needed since the server side already handles it correctly.