fix: use hashed chunk names for hash map

[zhangyx1998]

Description

Major changes

This update refactors page-chunk resolution to fix both problems in issue #5143: path-name collisions and unintentional route leakage.

• Replaced flattened filename mapping (/ → _) with deterministic hashed keys.
• Switched runtime lookup to a one-way map (canonicalPath -> assetKey -> lookupKey -> hash) so clients no longer have reversible page identifiers.
• Refactored chunk naming from [name].[hash].js to [assetKey].[hash].js.
• Added caseSensitive: boolean config entry.

flowchart LR

Canonical("<small>Maybe Private</small><br>Canonical Path _foo/bar_"):::orange
AssetKey("<small>DERIVED</small><br>Asset Key"):::yellow

subgraph Hashmap["<small>Client Hash Map</small>"]
LookupKey("<small>PUBLIC</small><br>Lookup Key"):::green
FileHash("<small>PUBLIC</small><br>FileHash"):::green
LookupKey --> FileHash --> LookupKey
end

subgraph Server["<small>Static File Server</small>"]
    Asset[("🔒 [AssetKey].[FileHash].js")]:::orange
    Bundler([🔨 Vitepress Bundler]):::blue
    Gateway((☁️)):::node
    Gateway --> Asset
end

Canonical --> AssetKey --> LookupKey

AssetKey --> Gateway
FileHash --> Gateway

linkStyle default stroke:gray,stroke-width:2px;

classDef node fill:#0004,stroke:currentColor,color:gray;
classDef green fill:#0004,stroke:currentColor,color:#AF0;
classDef orange fill:#0004,stroke:currentColor,color:#FA0;
classDef yellow fill:#0004,stroke:currentColor,color:#FF0;
classDef blue fill:#0004,stroke:currentColor,color:#0AF;

style Hashmap fill:#0001,stroke:gray,stroke-width:1px,stroke-dasharray:6 4,color:gray,opacity:0.6;
style Server fill:#0001,stroke:gray,stroke-width:1px,stroke-dasharray:6 4,color:gray,opacity:0.6;

Loading

Tip

Asset keys are never shared with the client. To resolve an asset key and load a chunk, the client must provide the correct canonical path. Since the client doesn't know the paths for unlisted pages, it cannot easily discover their asset URLs. This aligns with the expectation that unlisted files should not be trivially exposed, though it is not a 'cryptographically secure' solution.

Linked Issues

fixes #5143

/publish