Add vite-prefix attribute to ViteTagHelper to allow prefixed/relative manifest asset paths#177
Add vite-prefix attribute to ViteTagHelper to allow prefixed/relative manifest asset paths#177andrei-micuda wants to merge 1 commit intoEptagone:mainfrom
Conversation
- Add optional vite-prefix attribute for custom asset path prefixes - Support relative, absolute, and tilde-prefixed paths - Add comprehensive unit tests for all scenarios - Update documentation in README files
|
Hi, what's the difference of this vs setting a base path? |
|
Hi — thanks for reviewing this. For my use case I needed my Vite assets to be referenced with a document-relative path so they live under a subfolder inside wwwroot used for the React app (e.g. ../react/main.ts). I tried setting Vite's base in vite.config.ts, but that option requires an absolute or URL-like path and doesn't accept relative values like "../", so it couldn't produce document-relative URLs from the manifest. Because of that limitation I needed the ability to prepend a custom prefix (including relative prefixes such as ../) after manifest resolution — which is exactly what vite-prefix allows. Example: This keeps hashed filenames and CSS chunk discovery provided by the manifest, while allowing document-relative or proxy/CDN prefixes that Vite's base can't express. Happy to add any extra examples or a short integration note to the README if you want. |
Yes, please add an example project in |
Summary
This PR adds an optional
vite-prefixattribute to the existingViteTagHelper. When present, the helper will prepend the provided prefix to the manifest-resolved asset path before emitting thehreforsrcattribute. If the combined prefix+path begins with~, it is expanded usingUrlHelper.Content(soRequest.PathBasestill applies). Dev server behavior is unchanged, and manifest resolution is preserved.Motivation
When an ASP.NET Core app is hosted behind proxies that add dynamic external prefixes (for example
/sso/<guid>/...) or when you need assets referenced relative to the current document, emitting app-root absolute paths isn't flexible enough.This change preserves all the benefits of Vite's manifest (hashed filenames and CSS chunk discovery) while giving developers control over final URL generation through:
../for document-relative paths)/static/for CDN or specific mount points)~/prefix/forPathBase-aware URLs)Changes Made
ViteTagHelper.cs
[HtmlAttributeName("vite-prefix")] public string? VitePrefix { get; set; }ResolveCssFilePath()andResolveJsFilePath()helper methods to apply prefix logicVitePrefixis provided and non-empty, the tag helper prepends the normalized prefix to the resolved manifest path~,UrlHelper.Contentis used for expansion<link>tag generatedoutput.Attributes.RemoveAll(VITE_PREFIX_ATTRIBUTE)to ensure the custom attribute doesn't leak into HTML output'/','~') for better performanceDocumentation
README.md(root) withvite-prefixsection and examplessrc/library/Vite.AspNetCore/README.mdwith detailed usage examplesTests
src/tests/ViteNetProject.Tests/VitePrefixTests.cs../)/static/)~/prefix/)[Collection("Sequential")]attribute to prevent test isolation issuesDependencies
Backward Compatibility
✅ No breaking changes - this is a fully backward-compatible addition:
vite-prefixis not setvite-prefixattribute is completely optionalUsage Examples
Relative Prefix (Document-Relative Paths)
Static Prefix (CDN or Mount Point)
Tilde Prefix (PathBase-Aware)