fix(routing): use normalizePathSeparators(path.relative) instead of path.posix.relative - #2308
Merged
Conversation
…ath.posix.relative
commit: |
Contributor
Performance benchmarksCompared 0 improved · 1 regressed · 5 within ±1.5%
View detailed results and traces 🟢 improvement · 🔴 regression · ⚫ change below 1.5% · paired base/head |
…s_path.relative_instead_of_path.posix.relative
This was referenced Jul 2, 2026
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.
What
Replace every
path.posix.relative(a, b)withnormalizePathSeparators(path.relative(a, b)), and drop the now-stalepath.posix.relativementions from the surrounding doc comments:routing/app-route-graph.ts: the parallel-slotownerSegmentsand slotkey.check.ts:scanImports'relFileandcheckConventions'rel.plugins/og-assets.ts: the chunk-relative wasm URL.Why
path.posix.relativetreats its inputs as plain POSIX strings, so on Windows absolute paths it gets the drive/case semantics wrong:path.posix.relativenormalizePathSeparators(path.relative(...))C:/AppvsC:/app/dashboard../app/dashboarddashboardc:/appvsC:/app/dashboard../../C:/app/dashboarddashboardC:/appvsD:/other/x../../D:/other/xD:/other/xWindows filesystems are case-insensitive and drive-qualified, so an
appDir/rootwhose casing or drive differs from a scanned path would yield a corrupt relative path or key.path.relativeispath.win32.relativeon Windows and handles all of that correctly; normalizing its result back to forward slashes keeps the canonical id form. Forog-assets, the operands are bundle-relative paths (no drive), so the two forms are equivalent — it is unified anyway so there is no special case to reason about later.How
path.posix.relativecalls fornormalizePathSeparators(path.relative(...)).normalizePathSeparatorsimport tocheck.tsand added it toog-assets.ts.path.posix.relativeclauses from the affected doc comments (kept thepath.posix.joinnotes).Testing
vp check packages/vinext/src/routing/app-route-graph.ts packages/vinext/src/check.ts packages/vinext/src/plugins/og-assets.ts— format, lint, and typecheck clean.path.relative===path.posix.relative,normalizePathSeparatorsreturns its input). On Windows, relative paths are now computed with drive/case awareness, fixing corrupt slot keys / report paths when casing or drive differs.